Keylength – Cryptographic Key Length Recommendation

https://www.keylength.com/

by jonbaer • 10 years ago

53 42 10 years ago

You probably shouldn't even entertain the notion of RSA or finite field Diffie Hellman anymore. In general...

Public key encryption: Use X25519 (RFC 7748) then 256-bit symmetric-key encryption in an AEAD mode. (When in doubt, ChaCha20-Poly1305 is a great choice with ephemeral keys.)

Public key signatures: Use Ed25519 (RFC 7748) or deterministic ECDSA (RFC 6979) over a 256-bit curve.

And obviously, the key sizes on that page have no applicability to post-quantum cryptography key sizes.

geofft3• 10 years ago

A lot of us have to interoperate with systems that don't easily support Curve25519 or ChaCha20-Poly1305, let alone post-quantum algorithms. As RSA and finite-field DH aren't broken, I'd rather use a well-tested implementation of one of those with sufficient key length than try to backport a newer algorithm. (For new protocols and new code, sure.)

What I find this page useful for is pointing out lower bounds on security levels. If you're building a system that, eventually, outputs a file format with 256-bit hashes of files, there isn't a point in using any stronger crypto than a 128-bit security level to sign and transmit the hashes. If you want to make the system more secure, first figure out how to make the hashes longer.

CiPHPerCoder4• 10 years ago

As RSA and finite-field DH aren't broken

No, but their implementations often are. For a recent example (Zend Framework, just at the end of 2015): http://framework.zend.com/security/advisory/ZF2015-10

More famously: http://www.cryptofails.com/post/70059600123/saltstack-rsa-e-...

RSA has more knobs to turn than EdDSA, and leads greater room for implementor error.

tptacek14• 10 years ago

Implementation pitfalls for RSA are one problem, but not the only one. RSA systems also tend to intrinsically resist forward security (they beg for long-lived keys used directly to encrypt things) and have idiosyncratic padding requirements and message restrictions. These are design-level issues that libraries can't easily address for you.

Look at the deployed base of RSA systems, including modern ones, and note how few of them use OAEP and how many use PKCS1v15.

If you don't have a choice what algorithm you can use, I'm not so interested in what advice you're getting. Just do what everyone else tells you to do. But if you're in a place where you have real choices to make, the most important thing people can probably tell you is "don't use RSA, don't use conventional Diffie-Hellman".

tptacek14• 10 years ago

Key size does not matter. Algorithm selection and mode does.

eximius• 10 years ago

I mean, it does, the marginal utility for each bit of the key just drops off very quickly.

tptacek14• 10 years ago

I think people think I'm kidding. I am not.

Someone12345• 10 years ago

Obviously it matters. Yes, there are other important, even more important, choices when choosing a scheme, this is just attempting to address a single choice you may have to make.

Saying it "does not matter" is unhelpful hyperbole that isn't explained.

tptacek14• 10 years ago

No, with proper choices of algorithms, key size is literally irrelevant; without it, your problems are so big that key size is again irrelevant.

Counterexamples welcome.

peterwwillis2• 10 years ago

If key size did not matter, we would not have variable key sizes for the same algorithm and mode.

The most obvious case is brute forcing. Legacy systems are all trivially defeated by small key sizes once weaknesses in the algorithm are found. And quantum computing cuts the key size in half, effectively; symmetric algorithms that can double their key size is the only practical defense [that I know of].

If you have to use RSA or DH - and many people have to - you have to increase the key size. But doubling key size with RSA results in up to a 7x performance decrease. Key size matters.

tptacek14• 10 years ago

For good algorithms/constructions/primitives, like AES, even though there are selectable key sizes, they don't in practice matter (arguably they do in a post-quantum world, but they're the least of our concerns). There is no practical distinction between AES-128 and AES-256.

There is a significant practical difference between RSA-1024 and RSA-2048. But you shouldn't use RSA at all. You should avoid it, as much as possible, for other reasons.

I am militant about this point because key size selection is something everyone feels competent to nerd out about, but then they ship things like AES-256 running in unauthenticated CFB mode.

dsacco2• 10 years ago

I agree with this, but I think it could be phrased in a more nuanced way. I would state it thusly:

"Key size is a red herring. People fetishize key size because it's the most identifiable number and our monkey brains just want to make that number as large as possible. But key size is a not a dial you can tune in any context, and good cryptography depends on algorithms, not key sizes. A well-designed algorithm explicitly defines the key sizes you can select because it limits how much users can shoot themselves in the foot. The number of bits is not important, it's the way in which the algorithm creates a ciphertext using that number. Theoretically, a proven secure algorithm using an encryption function with a single bit key size would be perfectly fine to use."

I think that would be interpreted more charitably :). Then again, that's typing a lot more.

Hey for anyone reading this, this is basically why companies that state they use "bank-grade" or "128 bit" encryption on their cool landing pages aren't really saying anything.

MichaelGG• 10 years ago

Theoretically, a proven secure algorithm using an encryption function with a single bit key size would be perfectly fine to use

Can you elaborate? With a single bit key you can simply try both keys... right?

Keylength – Cryptographic Key Length Recommendation

Related Stories