Keylength – Cryptographic Key Length Recommendation(keylength.com)
keylength.com
Keylength – Cryptographic Key Length Recommendation
https://www.keylength.com/
2 comments
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.
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.
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".
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".
> 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.
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.
I'm confused. Above you're arguing for the use of newer schemes which are available with newer code which has not been as time-tested, here you're suggesting that the reason to avoid older well-tested schemes is poor implementation?
Aren't these two points contradictory. Unless you have a reason why the new scheme's implementation is more likely to be flawless than older implementations which may have received bug fixes or reviews. Seems to me that implementation bugs are a good reason to stick to older heavily used code, rather than jumping to the latest new thing.
Aren't these two points contradictory. Unless you have a reason why the new scheme's implementation is more likely to be flawless than older implementations which may have received bug fixes or reviews. Seems to me that implementation bugs are a good reason to stick to older heavily used code, rather than jumping to the latest new thing.
You're confused because you're unfamiliar with the concepts being discussed. That's not the same thing as being confused because the parent comment's argument is flawed.
RSA is dangerous for a bunch of reasons:
* It has selectable key sizes and performance parameters that beg people to deploy it insecurely. That's the concept you're probably roughly familiar with.
* It is subject to a far greater diversity of implementation faults (for instance: because of its padding requirements, or because of its relatively complicated key generation process) than alternative algorithms.
* It offers one primitive operation you actually want (signatures) along with one you almost never want (encryption), which results in cryptosystems like classical TLS or, worse, every system that ever directly encrypted a credit card number with RSA. Alternative algorithms don't offer this foot-gun.
* The underlying mathematics of RSA are weakening(/improving) faster than those of elliptic curve; we could lose RSA entirely within our lifetimes even if quantum doesn't come to pass.
You don't have to take my word for it. Survey modern cryptosystems. Note which ones depend on curves and which depend on RSA, and then investigate the reputations of each of those systems.
RSA is dangerous for a bunch of reasons:
* It has selectable key sizes and performance parameters that beg people to deploy it insecurely. That's the concept you're probably roughly familiar with.
* It is subject to a far greater diversity of implementation faults (for instance: because of its padding requirements, or because of its relatively complicated key generation process) than alternative algorithms.
* It offers one primitive operation you actually want (signatures) along with one you almost never want (encryption), which results in cryptosystems like classical TLS or, worse, every system that ever directly encrypted a credit card number with RSA. Alternative algorithms don't offer this foot-gun.
* The underlying mathematics of RSA are weakening(/improving) faster than those of elliptic curve; we could lose RSA entirely within our lifetimes even if quantum doesn't come to pass.
You don't have to take my word for it. Survey modern cryptosystems. Note which ones depend on curves and which depend on RSA, and then investigate the reputations of each of those systems.
> You're confused because you're unfamiliar with the concepts being discussed. That's not the same thing as being confused because the parent comment's argument is flawed.
That's very unnecessarily condescending. You then go on to criticise RSA, which is fine, but fails to address the point I made which was that they criticised RSA's implementation, not its inherent design flaws, while promoting a newer scheme with a less time-tested implementation.
This is verbatim what I was responding to:
> As RSA and finite-field DH aren't broken
>> No, but their implementations often are.
PS - I strongly suspect your tone is a result of another thread of discussion we had in this topic[0]. I'd suggest you make snide remarks there rather than carrying it over into this thread.
[0] https://news.ycombinator.com/item?id=11909436
That's very unnecessarily condescending. You then go on to criticise RSA, which is fine, but fails to address the point I made which was that they criticised RSA's implementation, not its inherent design flaws, while promoting a newer scheme with a less time-tested implementation.
This is verbatim what I was responding to:
> As RSA and finite-field DH aren't broken
>> No, but their implementations often are.
PS - I strongly suspect your tone is a result of another thread of discussion we had in this topic[0]. I'd suggest you make snide remarks there rather than carrying it over into this thread.
[0] https://news.ycombinator.com/item?id=11909436
Let me clarify a bit then: My criticisms of RSA stem from studying how people implement it in cryptography libraries.
More people implement PKCS1v1.5 padding than implement RSAES-OAEP in their application-layer crypto, and that's a problem.
Conversely, most of the applications I've analyzed that wanted ECDSA/ECDH used OpenSSL or libsodium.
Guess which ones were broken with chosen-ciphertext attacks.
If you want a theoretical concern: Index calculus attacks.
If you want a practical concern: Look at the traps that cause implementations to be comically insecure.
More people implement PKCS1v1.5 padding than implement RSAES-OAEP in their application-layer crypto, and that's a problem.
Conversely, most of the applications I've analyzed that wanted ECDSA/ECDH used OpenSSL or libsodium.
Guess which ones were broken with chosen-ciphertext attacks.
If you want a theoretical concern: Index calculus attacks.
If you want a practical concern: Look at the traps that cause implementations to be comically insecure.
None of this is responsive to the comment I just wrote. I'm pretty happy to leave this part of the thread where it is, though.
Curve25519 is very well tested too. Not as well tested as RSA, granted, but it has actually survived the testing, while RSA has several known problems.
Overall, creating an RSA implementation is a minefield. There is a big number of issues you must avoid, while Curve25519 doesn't suffer from most of them.
Overall, creating an RSA implementation is a minefield. There is a big number of issues you must avoid, while Curve25519 doesn't suffer from most of them.
I have no intention of creating an RSA implementation or a Curve25519 implementation. I'm going to use a high-level library that doesn't let me choose things like public exponent or padding style.
If the high-level libraries out there for X25519 are better-tested and less likely to get things wrong than those for RSA, sure, but that would be pretty surprising.
If the high-level libraries out there for X25519 are better-tested and less likely to get things wrong than those for RSA, sure, but that would be pretty surprising.
So, be surprised. They are.
Implementing RSA has many, many pitfalls. People are finding vulnerabilities on those libraries all the time. Now, take a look at libsodim source code - it's simple and direct, no special cases anywhere, no tests for validity. The only concern is with stuff like if the compiler will optimize out things like zeroing the memory and the platform has constant time opcodes.
Implementing RSA has many, many pitfalls. People are finding vulnerabilities on those libraries all the time. Now, take a look at libsodim source code - it's simple and direct, no special cases anywhere, no tests for validity. The only concern is with stuff like if the compiler will optimize out things like zeroing the memory and the platform has constant time opcodes.
Here's a high-level library: https://github.com/paragonie/halite
It uses libsodium, which only offers X25519/Ed25519 for public key crypto.
It uses libsodium, which only offers X25519/Ed25519 for public key crypto.
Key size does not matter. Algorithm selection and mode does.
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.
"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.
>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?
Can you elaborate? With a single bit key you can simply try both keys... right?
I believe what was meant was a single key size measured in bits, not just a 0 or 1.
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.
Saying it "does not matter" is unhelpful hyperbole that isn't explained.
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.
Counterexamples welcome.
HMAC-SHA256 is a secure and conservative choice for almost any application, but allows a variable key size. I'm sure I've seen deployments with a 0 bit key.
Most algorithms in use happen to be defined only for a 128 bit symmetric key or above, which is also the currently recommended key length, but that is incidental. There is no fundamental truth in your quote, it has been wrong in the past, and it will be wrong in the future.
Most algorithms in use happen to be defined only for a 128 bit symmetric key or above, which is also the currently recommended key length, but that is incidental. There is no fundamental truth in your quote, it has been wrong in the past, and it will be wrong in the future.
That's not really fair to say. The HMAC RFC[1] explicitly discourages key sizes of less than L bytes, which in context is about 128 bits. Variable key sizes can be chosen, sure, but it's not exactly a feature if there is an implicit lower bound.
I would say it is a fault of the HMAC construction that any key size can be selected, not a fault of using a key size HMAC is not designed for. An improvement would be explicitly defined key sizes that are compatible with other algorithms in an entire cryptosystem. If HMAC were to be built from scratch today, it would probably be better to have explicitly defined key sizes instead of variable key sizes.
I know this might come across as obtuse or stubborn, but if you read the other comment I made in this thread I think it might clarify my point.
[1]: https://tools.ietf.org/html/rfc2104#section-3
I would say it is a fault of the HMAC construction that any key size can be selected, not a fault of using a key size HMAC is not designed for. An improvement would be explicitly defined key sizes that are compatible with other algorithms in an entire cryptosystem. If HMAC were to be built from scratch today, it would probably be better to have explicitly defined key sizes instead of variable key sizes.
I know this might come across as obtuse or stubborn, but if you read the other comment I made in this thread I think it might clarify my point.
[1]: https://tools.ietf.org/html/rfc2104#section-3
KMAC is a proposed new MAC standard based on the Shake function used in SHA-3.
It explicitly is defined for all key sizes:
"K is the key, a byte string of any length. An empty string is a legal input."
It has some guidance about choosing a secure key size but ultimately libraries are likely to handle this the exact same way as with HMAC and allow users shoot themselves in the foot.
You can call it a "fault of the construction" if you'd like, but ultimately this is a secure construction that happens to allow insecure key sizes. You'll need to use it with a secure key size, or even better, use a library where someone has chosen the key size for you. It is not something you should need to think about as an end user, but it matters.
https://www.ietf.org/mail-archive/web/saag/current/pdfxrzR9r...
It explicitly is defined for all key sizes:
"K is the key, a byte string of any length. An empty string is a legal input."
It has some guidance about choosing a secure key size but ultimately libraries are likely to handle this the exact same way as with HMAC and allow users shoot themselves in the foot.
You can call it a "fault of the construction" if you'd like, but ultimately this is a secure construction that happens to allow insecure key sizes. You'll need to use it with a secure key size, or even better, use a library where someone has chosen the key size for you. It is not something you should need to think about as an end user, but it matters.
https://www.ietf.org/mail-archive/web/saag/current/pdfxrzR9r...
SHA-2 is a great example of what I'm talking about. The best SHA-2's to use don't have the highest output size.
w/r/t/ variable-sized HMAC key sizes: you don't need to "select" a key size, so much as you want it ideally to be harmonized with the key size of your cipher. Since you're going to use AES-128 anyways, this isn't a tricky decision.
w/r/t/ variable-sized HMAC key sizes: you don't need to "select" a key size, so much as you want it ideally to be harmonized with the key size of your cipher. Since you're going to use AES-128 anyways, this isn't a tricky decision.
You said key size does not matter. This post doesn't seem to relate to that at all.
Can you explain what you mean by "proper choices of algorithms"? WeakDH was an attack that was entirely about poor choices of key size and (to my knowledge) entirely remediable by better choices of key size. It's true that it could have also been solved by switching to a different algorithm, but for many of the affected servers, key size was easy to change and the different algorithm was not available.
Don't ever use conventional Diffie-Hellman. You'd have problems even with reasonable key sizes.
A key size of 1 bit.
No secure algorithm is defined at that key size.
There is no straightforward way to arrive at, say, 64 bit AES. Key size is not simply a dial you can turn everywhere.
There is no straightforward way to arrive at, say, 64 bit AES. Key size is not simply a dial you can turn everywhere.
> There is no straightforward way to arrive at, say, 64 bit AES.
Sure there is: zero-pad to 128, 192 or 256 bits. That'd be horribly, terribly broken, but it would be 64-bit AES. Horrible, terrible 64-bit AES, but AES nonetheless.
Sure there is: zero-pad to 128, 192 or 256 bits. That'd be horribly, terribly broken, but it would be 64-bit AES. Horrible, terrible 64-bit AES, but AES nonetheless.
I wrote "no straightforward way" in anticipation of someone coming up with some bizarre way to adapt AES to a small key size. If we all just stipulate that we understand how block ciphers work, we don't have to waste time in blind alleys like this.
> No secure algorithm is defined at that key size.
HMAC-SHA256 is.
HMAC-SHA256 is.
You said "key size is literally irrelevant," if it is "literally irrelevant" and you weren't just being hyperbolic then 1 bit should be sufficient.
You can definitely implement most algorithms to take in a 1 bit or 1 byte key, padding for one, just because it isn't widely supported doesn't change that fact.
So when you say something is "literally irrelevant" and ask for counterexamples, don't be surprised when someone gives them to you.
Obviously a 1 bit or 1 byte key is absurd. But so is claiming that key length is "literally irrelevant" and "does not matter."
You can definitely implement most algorithms to take in a 1 bit or 1 byte key, padding for one, just because it isn't widely supported doesn't change that fact.
So when you say something is "literally irrelevant" and ask for counterexamples, don't be surprised when someone gives them to you.
Obviously a 1 bit or 1 byte key is absurd. But so is claiming that key length is "literally irrelevant" and "does not matter."
RSA-1024? Still in use in many applications, considered extremely vulnerable.
Are you going to suggest that RSA itself is an improper algorithmic choice, in favor of elliptic curves? That option wasn't necessarily available to all users when some of these RSA deployments happened.
Edit: I see that you addressed this point elsewhere in this thread.
Are you going to suggest that RSA itself is an improper algorithmic choice, in favor of elliptic curves? That option wasn't necessarily available to all users when some of these RSA deployments happened.
Edit: I see that you addressed this point elsewhere in this thread.
Yes, that is what I'm saying.
I think you have a strong point that I hadn't considered in exactly these terms before. But (for example following your discussion with geofft) I'd suggest that it would best be qualified with "if you don't have backwards-compatibility considerations", since a lot of people continuing to use mechanisms that provide a flexible keylength parameter do have these considerations.
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.
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.
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.
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.
You are correct that AES's three key sizes are a result of the legacy of the military wanting "three levels of security" and NIST then asking for them. And since there is no requirement that they actually be more or less secure, they are practically equivalent - except for the known weakness in AES256, and the other in AES192, that don't present in AES128. In this sense, AES256 is somewhat shittier than AES128, even though there is no practical threat to anyone right now.
But in practice, the future does matter, both due to legacy systems and possible unknown attacks. If an unknown attack can drop the key space, and then over time that becomes a practical brute force, you've lost the game. Unless you raise your key size.
It's important to remember all the legacy cryptosystems that exist in embedded devices, all the support contracts that expire, and all the companies that go under and leave products that can only be tweaked and not upgraded. Lots of industries (healthcare, academia, government, embedded devices, 3rd party software, etc) rely on these products, and the more IoT is pushed the more crap is going to make its way into products that will never receive a firmware update. In some (many?) cases they will use shitty crypto, and the only defense that shitty crypto will have against the future is increasing the key size.
So the problem with your statement is you said key sizes don't matter. In reality, they just matter the least, right now.
But in practice, the future does matter, both due to legacy systems and possible unknown attacks. If an unknown attack can drop the key space, and then over time that becomes a practical brute force, you've lost the game. Unless you raise your key size.
It's important to remember all the legacy cryptosystems that exist in embedded devices, all the support contracts that expire, and all the companies that go under and leave products that can only be tweaked and not upgraded. Lots of industries (healthcare, academia, government, embedded devices, 3rd party software, etc) rely on these products, and the more IoT is pushed the more crap is going to make its way into products that will never receive a firmware update. In some (many?) cases they will use shitty crypto, and the only defense that shitty crypto will have against the future is increasing the key size.
So the problem with your statement is you said key sizes don't matter. In reality, they just matter the least, right now.
In a soundly built modern system, AES-128 is going to be the last component that falls. -256 does not actually buy you any meaningful security margin in such a system.
It simply doesn't matter. What matters is that you choose the right algorithms, the right modes, the right variants, the right authentication schemes, the right protocol designs. These are much harder problems, and the process of solving them will dictate your key sizes anyways.
It simply doesn't matter. What matters is that you choose the right algorithms, the right modes, the right variants, the right authentication schemes, the right protocol designs. These are much harder problems, and the process of solving them will dictate your key sizes anyways.
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.