In the same provocative vein, is nonce reuse that big of a deal without an associated cleartext leak of some kind? Or is it more like reducing cracking time from thousands of years to hundreds of years?
Not that I'm saying people should do obviously bad things, I'm just wondering how bad it is if some nonces get reused for a particular short-lived session key.
It was presented at Black Hat by injecting their slides into the MI6 website, IIRC, using this exact weakness.
It's not just a bad issue, it's also deceptively easy to run into and not realize it.
AES-GCM has a 96-bit nonce. If you sample these randomly, after 2^32 messages, you have a greater than 2^-32 chance of reuse for each subsequent message.
If you're using this algorithm with a static key to encrypt customer records, as a small business, you might never hit this bound.
If you're as large as a cloud provider, you get a nonce reuse every hour.
(Check out Amazon's KMS white paper if you'd like to see how they avoid this sharp edge in practice.)
why do cryptographers ever do things with fewer than 256 bits? like sure speed is nice, but it's also really nice to know that even if you have a birthday attack and lose another factor of a billion somewhere you're still fine.
Aes has a blocksize of 128bits, which so 96 bit is the nonce size that gets you a 32 bit counter. You probably don't want a smaller counter. Things xsalsa technically have a larger nonce but in reality still derive a smaller nonce.
Nonce reuse covers a whole bunch of attacks in different algorithms. It's weird to compare that broad category against two specific examples of padding oracle attacks
Not that I'm saying people should do obviously bad things, I'm just wondering how bad it is if some nonces get reused for a particular short-lived session key.