Key size does not matter. Algorithm selection and mode does.
"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?
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.