Am 14.11.2016 um 17:35 schrieb Alice Wonder: > 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. >
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. _______________________________________________ Ach mailing list [email protected] http://lists.cert.at/cgi-bin/mailman/listinfo/ach
