Date: Mon, 19 Oct 2015 17:40:14 -0400 From: Daniel Kahn Gillmor <dkg@...thhorseman.net> To: Seth Arnold <seth.arnold@...onical.com>, oss-security@...ts.openwall.com Subject: Re: Prime example of a can of worms On Mon 2015-10-19 15:34:11 -0400, Seth Arnold wrote: > Should there be any middle-ground for how much use a specific value gets? > Part of the weakdh gift is the reconition that randomly generated 1024 bit > primes might be fine for one router or website to use but is terrible when > used by millions and might repay the cost to crack it. > > Do we allow 1024-bit dhparams when they are randomly generated? Or do we > also want to move these to e.g. 2048 out of abundance of caution? we don't just want 1024-bit primes; we want 1024-bit safe primes (p = 2q+1, where both p and q are prime), because their structure makes it easy for both peers to avoid a small subgroup attack. safe primes are expensive to generate (for the party who selects the prime), and they are expensive to verify (on the side of the party who accepts the prime). These are difficult risks for peers to assess. For the peer who selects the group: how often should you re-generate a new prime? Should you share a prime with other parties in the same position as you, or should you choose your own? If you share a prime with other parties, how many parties are OK? how much traffic is safe to pass under the same group? For the peer who is offered the group, should you verify that the modulus you receive is a safe prime? Should you do a complete, rigorous proof or would a pair of probabilistic miller-rabin tests be ok? You could "cheat" and ignore the check and things will "just work" most of the time, and save your users some battery life. How should you reject an offered prime if you find it doesn't have the expected structure (non-safe primes could still produce valid groups, even though safe primes are easier to inspect for)? What if you think you've seen this prime before from too many other peers? Should you reject it then? All of these questions are really fuzzy and hard to give good guidance, and hard to know as an implementor that you're doing the right thing. On the flip side, saying "use only strong (>=2048bit today in 2015?), well-known, well-structured, publicly-vetted groups" is very simple guidance: clear and easy to follow. A move to well-known, large safe primes seems simpler/saner than trying to work with an environment where peers are generating new primes which may or may not be well-formed. (similarly, we're converging on a world where there are a few trusted, well-vetted, well-optimized DH groups for elliptic curve DH, because encouraging arbitrary ECDH groups ends up being sketchier for everyone) --dkg
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ