<div dir="ltr">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.<div>
<br></div><div>Aaron</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 11, 2013 at 11:10 PM, L. Aaron Kaplan <span dir="ltr"><<a href="mailto:kaplan@cert.at" target="_blank">kaplan@cert.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Dec 11, 2013, at 11:04 PM, Aaron Zauner <<a href="mailto:azet@azet.org">azet@azet.org</a>> wrote:<br>
<br>
> Hehe, at least you went with your own explaination. I looked it up and Bruce does that way better than I could. :)<br>
><br>
> 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].<br>

><br>
> 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.<br>

><br>
><br>
<br>
</div>ACK!<br>
That's also what Florian pointed us to.<br>
<br>
All right, I take it that we now have a clear picture what to write into the DH section.<br>
<span class="HOEnZb"><font color="#888888"><br>
a.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
---<br>
// L. Aaron Kaplan <<a href="mailto:kaplan@cert.at">kaplan@cert.at</a>> - T: <a href="tel:%2B43%201%205056416%2078" value="+431505641678">+43 1 5056416 78</a><br>
// CERT Austria - <a href="http://www.cert.at/" target="_blank">http://www.cert.at/</a><br>
// Eine Initiative der <a href="http://nic.at" target="_blank">nic.at</a> GmbH - <a href="http://www.nic.at/" target="_blank">http://www.nic.at/</a><br>
// Firmenbuchnummer 172568b, LG Salzburg<br>
<br>
<br>
<br>
<br>
</div></div></blockquote></div><br></div>