Re: Prime example of a can of worms

[Kurt Seifried <kseifried () redhat com>]

On Thu, Oct 22, 2015 at 4:55 PM, Daniel Kahn Gillmor <dkg () fifthhorseman net>
wrote:

> On Thu 2015-10-22 01:09:16 -0400, Kurt Seifried wrote:
> > Having a large pool of known good primes would be easier for them to use
> I
> > suspect. Sadly we can't let perfect be the enemy of the good, or in this
> > case the "not completely terrible".
>
> a large pool of known-good primes doesn't help so much, particularly for
> the embedded case -- peers that are offered a group need to be able to
> easily verify that the group is strong.  embedded devices simply aren't
> going to carry around a large list of well-vetted primes of short
> length, but we could *maybe* convince them to carry around a shorter
> list of well-vetted strong primes.
>
> I'd rather see us increase the security margin for a set of well-vetted
> standard groups than ask people to make implementations that can't
> determine whether they're in a reasonable group or not.
>
>      --dkg

Sorry when I said a "large" pool I meant more then the current 5 or so that
seem to be in popular use, but certainly not more than a few hundred.

Basically we're in agreement, I think nothing under 2048 should even be
considered, and we probably need to bump that up in a few years anyways.

I've also been going through source code to see how people use dh
params/treat them, and I have some worrying results (basically what I
expected though, everything is terrible as usual)

I'm going to be writing this up as an article rather than a long email as I
have a few more sticky points to raise (security rabbit holes are so much
fun).

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert () redhat com