[Ach] [cryptography] Diffie-Hellman Params Best Practice on Web Server?

[Aaron Zauner]

Hehe, at least you went with your own explaination. I looked it up and
Bruce does that way better than I could. :)

To simplify for people who don't want to go through Wikipedia reading up on
computations/arithmetic modulo prime and number theory (it's actually not
that bad as long as you find a good math text book with a chapter on number
theory in it): these parameters (groups and primes) are publicly known -
sent in plain at the beginning of the key exchange - and designed to be
publicly known. Pre-computation would not make much sense; since there are
different groups, and of course, many different primes to choose from. All
groups I'd feel comfortable to recommend are above 1536bits. i.e.
pre-computation is extremely unlikely. Whats-more - there are attacks on
some groups and subgroups that are outside of standard specifications or -
 for example - badly chosen at random [0] [1] [2].

Since I could not find a single source that recommends generation (and
regeneration) of DH parameters in a way that makes sense (i.e. describes
why that should be done - instead of just recommending it or configuring
services that do that) I'm convinced that we should stay with the
parameters as recommended by RFCs and implemented in various crypto
libraries.

Aaron

[0] http://www.ietf.org/rfc/rfc2785.txt
[1] http://en.wikipedia.org/wiki/Small_subgroup_confinement_attack
[2] http://crypto.stackexchange.com/a/10026


On Wed, Dec 11, 2013 at 10:50 PM, L. Aaron Kaplan <kaplan at cert.at> wrote:

> Damn, you beat me at answering Pepi's last mail :)
>
> On Dec 11, 2013, at 5:57 PM, Aaron Zauner <azet at azet.org> wrote:
>
> > Hi,
> >
> > The same holds true for RSA and factoring primes in general. If we go
> there we should consider telling people to turn away from modern technology
> (ted kaczynski manged that pretty well,.. oh. wait.).
> >
> (...)
>
>
> ---
> // L. Aaron Kaplan <kaplan at cert.at> - T: +43 1 5056416 78
> // CERT Austria - http://www.cert.at/
> // Eine Initiative der nic.at GmbH - http://www.nic.at/
> // Firmenbuchnummer 172568b, LG Salzburg
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cert.at/pipermail/ach/attachments/20131211/b7020868/attachment.html>