Re: [exim-dev] Bug#475194: D-H parameter generation is All W…

Pàgina inicial
Delete this message
Reply to this message
Autor: Marc Haber
Data:  
A: sacrificial-spam-address
CC: exim-dev, 475194, Tom Kistner
Assumpte: Re: [exim-dev] Bug#475194: D-H parameter generation is All Wrong
Dear anonymous crypto-expert,

On Sun, Apr 13, 2008 at 01:58:46PM +0200, Tom Kistner wrote:
> > It's also not very important that the D-H parameters be changed often;
>
> So there still is some value in changing them?
>
> > while changing them N times makes it N times as much work for an attacker
> > that wants to read ALL of your mail, it's better to just use a larger
> > prime and make it N times harder for an attacker to read ANY of your
> > mail.
>
> What about doing both? :)


It would help if you'd answer the question that Tom has asked three
weeks ago since you seem to have knowledge that only a few people on
this list have.

> > In fact, many cryptographic standards just specify a menu of fixed
> > D-H parameters for all implmentations for all time (e.g. RFC3526).
> > Generating a set once at install time is also reasonable. Changing it
> > daily is silly.
>
> 39.3 does not say "daily", it says "the frequency depending on your
> paranoia level". Now how paranoid should Debian be? I have no idea, and
> with my limited crypto skills, I can't give them a recommendation. Stock
> Exim does exacly what you want, compute D-H params exactly once.


And Debian has changed the DH parameter size to 2048 bits (hoping that
the patch I applied to tls-gnu.c #defining DH_BITS to 2048 and
PARAM_SIZE to 2*2048 was all that needed changing). Since generation
of 2048 bits DH parameters takes a long time even on recent systems, I
have disabled the generation of DH parameters completely, so all
Debian installations are now using a set of DH parameters generated at
packae build time. We still ship the script that was used to
regenerate the parameters daily, so local admins may choose to invoke
it on a regular basis.

I do sincerely hope that this is an acceptable compromise, I do not
have sufficient crypto knowledge to be a judge.

>
> > I might also mention that 1024 bits (which is O(2^80) operations to
> > break) is considered a bit small for serious security these days.
> > GNU TLS defaults to 2048 bits, a more reasonable default.
>
> Paranoia level again :)


I'd trust the GnuTLS people to know what they're doing and go with
their default.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190