[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87eggqmta9.fsf@alice.fifthhorseman.net>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
