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

[David Reid]

What some of the higher level recipe like things have to say about RSA key
sizes:

JWS[1]: "A 2048-bit or longer key length MUST be used with this algorithm."
DKIM[2]: "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.
OpenPGP[3]: "An implementation SHOULD NOT implement RSA keys of size less
than 1024 bits."
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.

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.

Surprisingly, I don't find myself having a particularly strong opinion
about limiting the key size at the hazmat layer.

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.

-David

--
1. http://tools.ietf.org/html/draft-jones-json-web-signature-04#section-6(Specifically
6.2)
2. http://tools.ietf.org/html/rfc6376#section-3.3.3
3. https://tools.ietf.org/html/rfc4880#section-13.5
4. https://code.google.com/p/keyczar/wiki/KeyczarSummary (this page is
likely out of date.)




On Tue, Feb 11, 2014 at 8:20 AM, alexs <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.
>
> On 11.02.2014 15:39, Alex Gaynor wrote:
>
> Hey all,
>
> 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.
>
> I am advocating for requiring that key_size be >= 1024. Here is why:
>
> * 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.
> * PyCrypto enforces a 1024 minimum, which means there is no difficulty in
> porting applications; as there would be if we used a larger minimum
> * Loosening the check in the future is much easier, from a backwards
> compatibility perspective, then tightening it.
>
> Thus, 1024 seems like a reasonable balance of these concerns.
>
> How do other people feel?
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
>
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140211/7544559d/attachment.html>