Live data from Hacker News

AES-GCM and breaking it on nonce reuse

frereit.de

1–10 of 64 posts

Re: AES-GCM and breaking it on nonce reuse

#2
Great post! Thanks for taking the time to put this up.

What do you think the ratios are regarding improper use of nonce with this mode?

Most implementations that I am familiar with intentionally generate a random nonce to help lower the percentage of app devs doing this very thing

Re: AES-GCM and breaking it on nonce reuse

#3
post #2

Great post! Thanks for taking the time to put this up. What do you think the ratios are regarding improper use of nonce with this mode? Most implementations that I am familiar with intentionally generate a random nonce to help lower the percentage of app devs doing this very thing

I think the writer is @frereit, they submitted 2 days ago https://news.ycombinator.com/item?id=40623885

Re: AES-GCM and breaking it on nonce reuse

#4
post #2

Great post! Thanks for taking the time to put this up. What do you think the ratios are regarding improper use of nonce with this mode? Most implementations that I am familiar with intentionally generate a random nonce to help lower the percentage of app devs doing this very thing

Correct. GCM is an improvement over ECB and CBC; it doesn't magically transform a symmetric algorithm into an asymmetric one. So most libraries are going to focus on the use cases where symmetric crypto makes sense, which are single-party scenarios such as disk storage. Google's Tink library, for example, completely hides the nonce parameter from its API.

Re: AES-GCM and breaking it on nonce reuse

#5
"At first glance, this seems fine, but it is not. If an attacker knows the plaintext p1 and the ciphertext c1, then they can compute the keystream by XORing p1 and c1 together"

Also, if the attacker only has c1 and c2, if the nonce is reused then c1 xor c2 will be the same as p1 xor p2. In most cases, two plaintexts xored with each other are trivial to decode.

Re: AES-GCM and breaking it on nonce reuse

#6
post #3
post #2

Great post! Thanks for taking the time to put this up. What do you think the ratios are regarding improper use of nonce with this mode? Most implementations that I am familiar with intentionally generate a random nonce to help lower the percentage of app devs doing this very thing

I think the writer is @frereit, they submitted 2 days ago https://news.ycombinator.com/item?id=40623885

Yes, I am, but unfortunately I do not think I can provide any answers here. A quick internet search reveals some CVEs for nonce reuse.

If I had to, based on absolutely nothing but a gut feeling, guess, I'd think this may appear more frequently in IoT devices, where AES-GCM is attractive because of its speed, but randomness is sometimes in low supply?

Re: AES-GCM and breaking it on nonce reuse

#8
post #2

Great post! Thanks for taking the time to put this up. What do you think the ratios are regarding improper use of nonce with this mode? Most implementations that I am familiar with intentionally generate a random nonce to help lower the percentage of app devs doing this very thing

The problem with a random nonce is that most implementations also use a nonce of 12 bytes which under some use cases might not be enough before you repeat a nonce. So to remedy this they suggest using a counter but this could be hard to implement.

When I use AES-GCM I just use a bigger nonce and use a random one.

Last time I used AES-GCM I had a really hard time getting the person writing the other end to not re-use nonces.

Re: AES-GCM and breaking it on nonce reuse

#9
post #7

It's worth mentioning AES-GCM-SIV[1], which is the fix for this issue. [1] https://www.rfc-editor.org/rfc/rfc8452.html

The alternative, which I prefer, is an XGCM-like construction that just gives you a large enough nonce to comfortably use random nonces.

Re: AES-GCM and breaking it on nonce reuse

#10
post #6
post #3

Earlier quoted context omitted.

I think the writer is @frereit, they submitted 2 days ago https://news.ycombinator.com/item?id=40623885

Yes, I am, but unfortunately I do not think I can provide any answers here. A quick internet search reveals some CVEs for nonce reuse. If I had to, based on absolutely nothing but a gut feeling, guess, I'd think this may appear more frequently in IoT devices, where AES-GCM is attractive because of its speed, but randomness is sometimes in low supply?

AES-GCM is also used in the Bluetooth Low Energy protocol, which is commonly used for IoT-purposes. As a result it’s more often than not available as a hardware-accelerated peripheral, saving both time and power. There’s also hardware-RNG available in those cases.

I think one reason nonce-reuse is a problem in IoT is lack of experience and awareness. Up until relatively recently a lot of embedded development was constrained to just offline devices, so cryptography wasn’t really required.

Post reply on HN