-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 17.04.2014 17:49, Mick wrote:
> On Thursday 17 Apr 2014 15:40:04 Matti Nykyri wrote:
>> On Apr 17, 2014, at 9:10, Mick <michaelkintz...@gmail.com>
>> wrote:
>>> On Wednesday 16 Apr 2014 18:56:57 Tanstaafl wrote:
>>>> On 4/16/2014 7:14 AM, Matti Nykyri <matti.nyk...@iki.fi>
>>>> wrote:
>>>>> On Apr 16, 2014, at 13:52, Tanstaafl
>>>>> <tansta...@libertytrek.org> wrote:
>>>>>> Or will simply replacing my self-signed certs with the
>>>>>> new real ones be good enough?
>>>>>
>>>>> No it will not. Keys are te ones that have been
>>>>> compromised. You need to create new keys. With those keys
>>>>> you need to create certificate request. Then you send that
>>>>> request to certificate authority for signing and publishing
>>>>> in their crl. When you receive the signed certificate you
>>>>> can start using it with your key. Never send your key to CA
>>>>> or expect to get a key from them.
>>>>
>>>> Ok, thanks...
>>>>
>>>> But... if I do this (create a new key-pair and CR), will
>>>> this immediately invalidate my old ones (ie, will my current
>>>> production server stop working until I get the new certs
>>>> installed)?
>>>
>>> You have not explained your PKI set up. Creating a new private
>>> key and CSR is just another private key and CSR.
>>>
>>> If you replace either the private CA key on the server, or any
>>> of its certificates chain, but leave the path in your vhosts
>>> pointing to the old key/certificate that no longer exist you
>>> will of course break the server. Apache will refuse to restart
>>> and warn you about borked paths.
>>>
>>>> I'm guessing not (or else there would be a lot of downtime
>>>> for lots of sites involved) - but I've only ever done this
>>>> once (created the key-pair, CR and self-signed keys) a long
>>>> time ago, so want to make sure I don't shoot myself in the
>>>> foot...
>>>
>>> Yes, better be safe with production machines. However, don't
>>> take too long because your private key(s) are potentially
>>> already compromised.
>>>
>>>> I have created new self-=signed certs a couple of times since
>>>> creating the original key-pair+CR, but never created a new
>>>> key-pair/CR...
>>>>
>>>>> There are also other algorithms the RSA. And also if you
>>>>> wan't to get PFS you will need to consider your setup,
>>>>> certificate and security model.
>>>>
>>>> What is PFS?
>>>>
>>> http://en.wikipedia.org/wiki/Forward_secrecy
>>>
>>> I'm no mathematical genius to understand cryptography at
>>> anything more than a superficial level, but I thought that
>>> ECDS, that PFS for TLS depends on, was compromised from
>>> inception by the NSA? Perhaps only some ECDS were, I am not
>>> really sure.
>>
>> I don't know anything about ECDS. You probably mean ECDSA?! What
>> i have understood is that ECDSA is not compromised. Though I can
>> not be certain about that.
>>
>> RSA has been in the market for a long time and the mathematics
>> are for what i think a bit simpler. But with compromised software
>> there was a bad algorithm for creating the primes. So it was the
>> keys not RSA it self. But I think the thing that you are talking
>> about is DHE_RSA... I read from somewhere that it was quite
>> compromised.. But ECDHE is not. The difference with DH and DHE
>> (ECDH and ECDHE) is that DH uses static keys and DHE
>> authenticated ephemeral keys. These temporary keys give you
>> forward secrecy but decrease performance.
>>
>> RSA takes quite heavy computing for the same level of security
>> compared to ECDSA. RSA key creation is even more costly so using
>> ephemeral temporary keys with RSA takes quite long to compute.
>> Thats why I prefer ECDHE_ECDSA suites for reasonable security and
>> fast encryption.
>>
>>> I remember reading somewhere (was it Schneier?) that RSA is
>>> probably a better bet these days. I'd also appreciate some
>>> views from the better informed members of the list because
>>> there's a lot of FUD and tin hats flying around in the post
>>> Snowden era.
>>
>> For high security application I would also use RSA in excess of
>> 16k keys. Then make sure to use random data and a trustworthy
>> key-generator. Fighting the agencies is still something I believe
>> is virtually impossible ;)
>
> Thanks Matti,
>
> Can you please share how you create ECDHE_ECDSA with openssl
> ecparam, or ping a URL if that is more convenient?
>
I don't think you realy want DSA, but here it is for DH, EC and DSA:
openssl genpkey -genparam -algorithm DH \
-pkeyopt dh_paramgen_prime_len:4096 \
-out /path/dh_params.pem
openssl genpkey -genparam -algorithm EC \
-pkeyopt ec_paramgen_curve:secp384r1 \
-out /path/ec_params.pem
openssl genpkey -genparam -algorithm DSA \
-pkeyopt dsa_paramgen_bits:1024 \
-out /path/dsa_params.pem
- --
Kind Regards, Mit freundlichen Grüssen,
Markus Kohlmeyer Markus Kohlmeyer
PGP: 0xEBDF5E55 / 2A22 1F71 AA70 1AD1 231B 0178 759F 407C EBDF 5E55
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQIcBAEBCgAGBQJTUAcrAAoJEHWfQHzr315VTxUP/0KdnN2CBvcQe7qOKEcnXkNq
p5DzcBFacq9Opp3/ICUZ21yLla/YA+QuiEoSOQS859xkFnqCVrAOvOLsVS7GJfTG
jUUWUEsd6YoxWGZql+m4P92HzTnL1cQAfc2kcd8vI6d0jCDqo3iLBcLwVuV/efz2
qtagFyIeFPAgGQ1RmTptIqc28IL8ugbL8HqePuc5pM8pOyfj7qwHI+64vVKiO+Xu
S+orO9nFtDnM7crTz68722qE4+58hj4q/w0N6Uuw8SJbFCDcaal063Ba2WSh+UHm
GBXidaK2eVdyTzzPx0rvkxMtD9sVb6WTZZ/gBwtJUNZ5WTinvjmQNDqkyWRxHeXP
e4m3mJCB36gdgjjy/0Kmt78otYblVkmI+JYRI4fH3l9fxT14FNuXq63R7aZuFEw2
BiwmR+naf2sxkiAhy/szybfqAmeVGKjEAqlDZkzEz6tlO6SwKkYBpc1QS139QHUN
bK++/bhzIh/yNEQjHIhEaMXmRTco+6fdASaq0h4r1mm5A8o0SCSJnNKp4G6ZC1SV
kuuYfiSHxpRZ0RoLUsFSZM7oki/j2Q1KYZys917/sLzLeOv2US2ScliEZD5w+mF0
e1cqudLoYP9TSkF/3r/ac5yF6gR4ye1eDEdCFeG2ktq8Ru/JlviiNAspSlm2OOAz
kFKkM0cJWaZ/mAuXrrfY
=GSjk
-----END PGP SIGNATURE-----
