On 2016-11-14T15:16, [email protected] <[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. > > Danial Bernstein about DSA and other broken standards: > https://blog.cr.yp.to/20140411-nist.html
Yes, however, there is an easily available (and hopefully widely used) mitigation for the randomness problem: the 'random' number can be deterministically derived from the secret key and the message (e.g. by hashing), eliminating the need for secure randomness. The number just needs to be un-guessable for the attacker and unlikely to be reused with a different message. But generally I'm suspicious of the current 'elliptic curves == good' automatism applied to everything in the field. However, this is somewhat independent of DSA. Ciao, Alexander Wuerstlein. _______________________________________________ Ach mailing list [email protected] http://lists.cert.at/cgi-bin/mailman/listinfo/ach
