5 ms·
Your comment shows a very dangerous misunderstanding of this issue. One of the reasons WeakDH/Logjam was so bad is because OpenSSL is so low-level that it force
by agwa 10y ago
Your comment shows a very dangerous misunderstanding of this issue. One of the reasons WeakDH/Logjam was so bad is because OpenSSL is so low-level that it forces application developers to supply their own DH parameters if they want to use Diffie-Hellman. Until recently, setting DH parameters required writing complicated code which required the application developer to understand obscure details of TLS like export ciphers, as well as whether it was safe to reuse temporary Diffie-Hellman keys.
In other words, OpenSSL forced developers to do crypto to use Diffie-Hellman. Unsurprisingly, developers did a poor job, and we got WeakDH/Logjam/CVE-2016-0701 as a result. The answer is not more hand-rolled crypto as you suggest, but rather better crypto libraries written by experts that leave as few details to the application developer as possible.
- javajosh 10y agoSo basically your point is that if app devs can't get DH parameters right, how on earth will they get the harder stuff right? I think that's a fine point, but you aren't really addressing the core concern, which is that "better crypto libraries written by experts" are precisely the ones most likely to be vulnerable to state actors doing massive prime computations. And by extension, state actors benefit from homogeneity of implementation. Even if it takes a day for a kid at the NSA to break my custom crypto, that's better than if I use homogenous crypto that takes 2ms to break. And if everyone is using bad custom crypto, that's a lot of time needed to break each one individually. The argument is very close to that against monolithic grain cultures that, while they have the best yields, resisitance to pests, and so forth, they are also more vulnerable to as-yet-unknown diseases. Bio-diversity is a good defense against that contingency.
- agwa 10y agoNo, because there's a simple solution to state actors doing massive computations: make the parameters so large (2048 bits in the case of DH) that the computations are infeasible. DH precomputation attacks are only a problem with smaller prime sizes (e.g. 1024 bits). Experts have always known to avoid small parameters, but developers copy-and-pasted them into their code without knowing they were bad.
- Laforet 10y agoThis is kind of parallels what happened with MD5 fingerprints in X509 certificates: for years the writing was on the wall that MD5 collision was imminent with better algorithm and more computing power, yet it took a number of practical exploits by individual researchers to convince the industry that MD5 has to go away. One good thing to have come out of it was that we really learned about the importance to future proof our crypto and the phase-out of SHA1 was carried out a lot more elegantly. Similarly, it is expected now that state level actors can already break 1024 bit RSA and 128 bit symmetric ciphers may be the next thing to fall. Hence their use should be avoided wherever possible.
- javajosh 10y agoThat's a very good point, but I don't think it invalidates the "biodiversity" argument. It's a different kind of defense, but it is a defense. For example, if there is a breakthrough in prime factorization, then heterogenous implementations may be the only security left to us.
- collinmanderson 10y agoHow much is DH used currently? Isn't https traffic mostly ECDHE now? Hasn't the issue mostly been fixed now? https://www.ssllabs.com/ssltest/analyze.html?d=news.ycombinator.com&s=104.20.44.44 https://www.ssllabs.com/ssltest/analyze.html?d=news.ycombina...