Keylength – Cryptographic Key Length Recommendation
keylength.com
keylength.com
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.
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.
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.
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.
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.
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.
It uses libsodium, which only offers X25519/Ed25519 for public key crypto.
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.
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.
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.
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.
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".
Saying it "does not matter" is unhelpful hyperbole that isn't explained.
Counterexamples welcome.
There is no straightforward way to arrive at, say, 64 bit AES. Key size is not simply a dial you can turn everywhere.
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."
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.
HMAC-SHA256 is.
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.
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.
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.
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...
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.
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.
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.
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.
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.
"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.
Can you elaborate? With a single bit key you can simply try both keys... right?