<br><br>On Tuesday, February 11, 2014, Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div>On Feb 11, 2014, at 11:20 AM, alexs <<a href="javascript:_e(%7B%7D,'cvml','alexs@prol.etari.at');" target="_blank">alexs@prol.etari.at</a>> wrote:</div>
<br><blockquote type="cite">
<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><br></div></div></blockquote><div><br></div>i also agree that this is the wrong level to be doing this in. High level API’s outside of the hazmat API can absolutely and should restrict key sizes. I don’t believe the low level APIs should.</div>
<div><br></div></div></blockquote><div><br></div><div>Low level API shouldn't probably try to enforce hard limits on key sizes. However, I do think they should Raise a SecurityWarning (or smtg similar) or at least log/print a warning when using keys < 2048 bits. Also when generating keys, the default keysize should be 4k as it is the largest universally supported key size.</div>
<div><br></div><div>Just my two cents (from a non-contributor for time being),</div><div><br></div><div><< Kimvais</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><br>-----------------<br>Donald Stufft<br>PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

</div></div></blockquote><div> </div>