[Cryptography-dev] RSA key generation -- minimum key size?

[Kimmo Parviainen-Jalanko]

On Tuesday, February 11, 2014, Donald Stufft <donald at stufft.io> wrote:

>
> On Feb 11, 2014, at 11:20 AM, alexs <alexs at prol.etari.at<javascript:_e(%7B%7D,'cvml','alexs at prol.etari.at');>>
> wrote:
>
> I am fine with there being a lower bound, I just don't think 1024 is the
> right number.
>
>  * 1024-bit is deprecated by every major standards body with an opinion on
> these things.
>
>  * 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.
>
>  * 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.
>
>  * 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?
>
> * 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.
>
> * 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?
>
> * This is hazmat, there are dinosaurs with laser guns in the documentation
> to warn you about this stuff.
>
> 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.
>
> 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.
>
>
> 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.
>
>
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.

Just my two cents (from a non-contributor for time being),

<< Kimvais



> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
> DCFA
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140211/4bd5ff80/attachment.html>