On 11/13/2016 06:08 PM, [email protected] 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?
_______________________________________________
Ach mailing list
[email protected]
http://lists.cert.at/cgi-bin/mailman/listinfo/ach
