[Ach] Cipher List Notes

[femir at qweepi.de]

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.
The attack surface of DSA in comparison to RSA is a billion times
larger. And having some kind of mitigation for some of those attack
vectors does not keep crypto experts like Daniel Bernstein and other
from discuraging the use of DSA.

And in regard to elliptic curve crypto there is also the future problem
of quantum computers. Although this is probably not relevant in the next
20 years, because of the lesser key size of ecc keys (like 256 bit
size), they will be the first ones to be broken, maybe years bevor 2048
bit rsa. I thnik Bruce Schneier had something about this on his blog.

My point is: ecc is somewhat dead already as it will not be useful for a
long period of time. Whether you use ecc at all or not, the future will
belong to post quantum crypto. In the end the extra computing power
needed for DHE and RSA is not a major aspect in light of todays
processing speed. And for key exchange ECDHE is already widely used
anyway. Switching to ECDSA certificates does not seem that useful to me.
It will rather decrease security if you believe some of those experts at
least.

I would like to know what the other think about this.