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

[Aaron Zauner]

BTW. there is a thing that we completely forgot to mention until now: keys
do in fact get weaker over time especially with protocols serving much
traffic and that those keys should be renewed regularly. This affects other
parts of the paper as well.

Aaron


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

>
> On Dec 11, 2013, at 11:04 PM, Aaron Zauner <azet at azet.org> wrote:
>
> > 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.
> >
> >
>
> ACK!
> That's also what Florian pointed us to.
>
> All right, I take it that we now have a clear picture what to write into
> the DH section.
>
> a.
>
>
> ---
> // 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/3d2511fc/attachment.html>