<div dir="ltr">What some of the higher level recipe like things have to say about RSA key sizes:<div><br></div><div>JWS[1]: "<span style="color:rgb(0,0,0);font-size:1em">A 2048-bit or longer key length MUST be used with this algorithm."</span></div>
<div><span style="color:rgb(0,0,0);font-size:1em">DKIM[2]: "</span><span style="color:rgb(0,0,0);font-size:1em">Signers MUST use RSA keys of at least 1024 bits for long-lived keys." It then fails to define long-lived keys. But the basic idea is that you can rotate keys frequently to deal with weaknesses of smaller keys.</span></div>
<div><span style="color:rgb(0,0,0);font-size:1em">OpenPGP[3]: "</span><span style="color:rgb(0,0,0);font-size:1em">An implementation SHOULD NOT implement RSA keys of size less than 1024 bits."</span></div><div>KeyCzar[4]: Smallest supported key size is 512 in C++ and Python implementations, with 2048 being the default. Smallest key size on Java is 1024 and default is 4096.</div>
<div><span style="color:rgb(0,0,0);font-size:1em"><br></span></div><div><span style="color:rgb(0,0,0);font-size:1em">That is just a quick survey, and is by no means comprehensive. But when we talk about enforcing key limits at a higher level these are the kinds of systems we're talking about implementing.</span></div>
<div><br></div><div>Surprisingly, I don't find myself having a particularly strong opinion about limiting the key size at the hazmat layer. </div><div><br></div><div>I do however find myself leaning slightly in favor of it because we don't have default values in hazmat, python's warnings are useless, and the cost of repainting the bike shed is so low.</div>
<div><br></div><div>-David</div><div><br></div><div>--</div><div><font color="#000000">1. <a href="http://tools.ietf.org/html/draft-jones-json-web-signature-04#section-6">http://tools.ietf.org/html/draft-jones-json-web-signature-04#section-6</a> (Specifically 6.2)</font></div>
<div><font color="#000000">2. <a href="http://tools.ietf.org/html/rfc6376#section-3.3.3">http://tools.ietf.org/html/rfc6376#section-3.3.3</a></font></div><div><font color="#000000">3. <a href="https://tools.ietf.org/html/rfc4880#section-13.5">https://tools.ietf.org/html/rfc4880#section-13.5</a></font></div>
<div><font color="#000000">4. <a href="https://code.google.com/p/keyczar/wiki/KeyczarSummary">https://code.google.com/p/keyczar/wiki/KeyczarSummary</a> (this page is likely out of date.)</font></div><div><br></div><div><font color="#000000"><br>
</font></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 11, 2014 at 8:20 AM, alexs <span dir="ltr"><<a href="mailto:alexs@prol.etari.at" target="_blank">alexs@prol.etari.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div>
<p>I am fine with there being a lower bound, I just don't think 1024 is the right number.</p>
<p> * 1024-bit is deprecated by every major standards body with an opinion on these things.</p>
<p> * 1024-bit doesn't seem to actually provide the benefit you'd want from a lower bound of making it harder for users to end up with factorable keys. As Alex Gaynor points out, nation states can probably break 1024-bit keys anyway.</p>
<p> * Smaller keys, in particular 768-bit (and even 512-bit until recently) signing keys are still in common usage in DKIM as they can be rotated frequently and the harm of an attack is much lower than in e.g. TLS.</p>
<p> * Users coming from PyCrypto shouldn't be using 1024-bit keys. Is there an application we know about that having to use a higher minimum would actually cause problems?</p>
<p>* This doesn't actually improve security much since we will still load much smaller keys from disk and also (presumably?) accept them when verifying signatures.</p>
<p>* If this is about security, do we have to update this limit as research progresses? What happens to users relying on downstream packages in e.g. Debian?</p>
<p>* This is hazmat, there are dinosaurs with laser guns in the documentation to warn you about this stuff.</p>
<p>I think the limit should either be 512-bit because it's the smallest key size with any significant usage in the recent past so I doubt anyone would even notice it. Or it should be 2048-bit because that's what everyone actually recommends. 1024-bit seems to be the worst of both worlds.</p>
<p>My preference is for 512-bit because I think this is the wrong place to be trying to improve security. The right place might be in something like a JSON Web Signatures or other higher level module where its more feasible to enable users to reject insecure keys at verification time.</p>
<div><div class="h5">
<p>On 11.02.2014 15:39, Alex Gaynor wrote:</p>
<blockquote type="cite" style="padding-left:5px;border-left:#1010ff 2px solid;margin-left:5px;width:100%">
<div dir="ltr">Hey all,
<div> </div>
<div>The last major issue blocking landing RSA key generation is a discussion over whether or not to enforce a minimum key size for newly generated keys.</div>
<div> </div>
<div>I am advocating for requiring that key_size be >= 1024. Here is why:</div>
<div> </div>
<div>* Smaller keys are factorable (768 is known to be factored publicly, it's extremely likely even larger is factorable by nation states); there is basically no reason to use these keys.</div>
<div>* PyCrypto enforces a 1024 minimum, which means there is no difficulty in porting applications; as there would be if we used a larger minimum</div>
<div>* Loosening the check in the future is much easier, from a backwards compatibility perspective, then tightening it.</div>
<div> </div>
<div>Thus, 1024 seems like a reasonable balance of these concerns.</div>
<div> </div>
<div>How do other people feel?</div>
<div>Alex</div>
<div>
<div> </div>
-- <br>
<div dir="ltr">"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)<br> "The people's good is the highest law." -- Cicero<br>
<div>GPG Key fingerprint: 125F 5C67 DFE9 4084</div>
</div>
</div>
</div>
</blockquote>
<p> </p>
<div> </div>
</div></div></div>
<br>_______________________________________________<br>
Cryptography-dev mailing list<br>
<a href="mailto:Cryptography-dev@python.org">Cryptography-dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/cryptography-dev" target="_blank">https://mail.python.org/mailman/listinfo/cryptography-dev</a><br>
<br></blockquote></div><br></div>