[Ach] Cipher List Notes

Alice Wonder alice at librelamp.com
Mon Nov 14 17:35:25 CET 2016


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.

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?


More information about the Ach mailing list