[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANO=Ty3BGrXMkocF2Vp-wXJVE_oo5K4dSA4+H-son_dzuMo4ZQ@mail.gmail.com>
Date: Thu, 22 Oct 2015 17:37:49 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: Daniel Kahn Gillmor <dkg@...thhorseman.net>
Cc: oss-security <oss-security@...ts.openwall.com>
Subject: Re: Prime example of a can of worms
On Thu, Oct 22, 2015 at 4:55 PM, Daniel Kahn Gillmor <dkg@...thhorseman.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@...hat.com
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.
