[616c]

> I think this bug is probably a contender for the top 3 practical cryptography vulnerabilities on the Internet. Its close cousin, Vaudenay's CBC padding oracle, is a lock for #1. Then it's just down to whether nonce reuse is #2 or #3.

Is this top 3 list from some public resource that exists and I am a noob who missed the reference and how the community knows what the Top 3 are? If not a resource would love to see it or help make it.

P.S. Been loving SCW podcast from time to time when I can list, keep up the good work!

[tptacek]

Nope, it's off the top of my head, and partially proffered as a provocation to other professionals to protest.

[woooooo]

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.

[tptacek]

Nonce reuse in CTR, which underpins a bunch of AEADs, gives you direct plaintext recovery. It leads to a repeated keystream.

Nonce reuse in nonce-based AEADs gives you authentication key recovery; it destroys authentication completely.

[some_furry]

Yes, it's that bad. See Hanno's talk a few years ago about nonce reuse.

https://www.usenix.org/conference/woot16/workshop-program/pr...

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.)

[adgjlsfhk1]

> AES-GCM has a 96-bit nonce.

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.

[technion]

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.

[tptacek]

Right, but the larger key (in XSalsa and X-everything-else) effectively gets mixed into the key, which is fine.

[acer4666]

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

[616c]

Would love to see such a resource, would a static site for a leaderboard be enough to maintain a top 10 list, even for drama and protest?