Re: Prime example of a can of worms

[Florent Daigniere <florent.daigniere () trustmatta com>]

On Wed, 2015-10-21 at 23:09 -0600, Kurt Seifried wrote:
> On Wed, Oct 21, 2015 at 10:45 PM, Joshua Rogers <oss () internot info>
> wrote:
>
> > On 22/10/15 15:27, Kurt Seifried wrote:
> > > Ideally we'd like
> > > to see people using different primes (e.g. hardware manufacturers
> > > not
> > using
> > > the same primes as everyone else) and where possible people
> > > needing more
> > > security (e.g. a VPN hosting provider) should generate their own
> > > keys
> > > securely.
> > Could it be possible to generate a new prime in the background, and
> > when
> > it has been generated, on the next reboot use that one instead? And
> > if
> > there is not enough time for the new prime to be generated, it
> > falls
> > back to the old one?
> >
> > I agree that manufacturers should be using a different prime per,
> > at
> > least, batch of products.
> My fear would be device makers getting it horribly wrong on the
> devices in
> question. E.g.:
>
> http://www.theregister.co.uk/2015/10/21/german_govt_mulls_security_te
> sts_of_sohopeless_routers/
>
> 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".

I still don't get why people are pushing for "non-standard" groups.
What you need is a good security margin...

No one should be using 1024bit DH groups anymore and 2048 bit groups
should have disappeared *before* ~2020

http://www.keylength.com/en/3/

If we want PFS to work in practice we need "auditable" deployments...
and that won't be possible with custom DH groups (verifying the
security/suitability of a group is non-straightforward as the rest of
the thread has pointed out).

Really, what are we after here? 
- Preventing pre-computation? Pick a larger group.
- Avoiding "massive" problems in case the standardized groups do turn
out to be unsuitable (sub-groups, ...)?
- Something else?


Florent

Attachment: signature.asc
Description: This is a digitally signed message part