[Ach] Cipher List Notes

[Alice Wonder]

On 11/14/2016 11:07 AM, femir at qweepi.de wrote:
> Am 14.11.2016 um 17:35 schrieb Alice Wonder:
>> On 11/13/2016 06:08 PM, femir at qweepi.de wrote:
>>> Am 12.11.2016 um 03:32 schrieb Alice Wonder:
>>>> For my equivalent of your Configuration A list, on servers where
>>>> sensitive information is transferred to and from the server, I do limit
>>>> it to TLS 1.2 and I also only use ECDSA certificates, I haven't yet come
>>>> across a user with a client that can do TLS 1.2 that doesn't handle
>>>> ECDSA.
>>>
>>> Why use (EC)DSA?
>>> DSA based cripto is the first thing that I would deactivate. Many other
>>> guides recommend disableing DSA as well.
>>> Compared to RSA, DSA has some attack vectors that are just unneccessary:
>>>
>>> For many operations DSA needs randomness, but in contrast to RSA,
>>> repeated use of the same random data or otherwise compromised random
>>> number generators will not only compromise the security of the specific
>>> operation. If the random numbers are not the best quality, then it is
>>> possible to compromise YOUR PRIVATE KEY.
>>
>> I use ECDSA because RSA keys are pretty much at their limit, beyond
>> 2048-bit the computation required increases for little gain.
>>
>> With respect to flawed random generators, solutions like haveged really
>> help mitigate lack of entropy issues.
>>
>
> haveged is also a solution that looks highly suspicious if you ask me.
> Generating random numbers is a very hard and complex matter and the devs
> that created generators like /dev/random on linux have put a lot of
> thought into it. Having something like haveged "easily" generate large
> amounts of randmoness leaves the question why didn't the other
> generators use the same technique. It doesn't look trustworthy to me.
>
> But haveged is also a kind of different topic although I would love to
> know what the others think about it.
>
>> If there is a flaw in the random generator, the private keys generated
>> for the forward secrecy are already suspect and honestly that is a
>> bigger concern than the server private key that really is only used for
>> authentication as DNSSEC helps to prevent many MITM type attacks even
>> when a private key is compromised (granted that assumes the client
>> enforces DNSSEC)
>>
>> PFS though means the actual connection is encrypted with an ephemeral
>> key, so if the random generator is flawed then the session is vulnerable
>> even if the server private key is not compromised, no?
>
> There is a key missunderstanding here. Having a broken random number
> generator is the worst case scenario. But having a number generator with
> a minor flaw, will not affect RSA keys, while it will breakt DSA keys.

But with forward secrecy new keys are generated for each session in 
which case even RSA keys could be cracked faster than brute force even 
if the long term key wasn't cracked and was generated on a machine with 
a proper generator.