11–20 of 64 posts
It's worth mentioning AES-GCM-SIV[1], which is the fix for this issue. [1] https://www.rfc-editor.org/rfc/rfc8452.html
But, AES-GCM-SIV requires two passes over the data, which isn't always ideal.
The goal of the CAESAR competition [1] was essentially to find alternatives. Whether that goal has been met is a bit unclear at the moment.
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.
...a variant on that is DNDK-GCM in draft at https://datatracker.ietf.org/doc/draft-gueron-cfrg-dndkgcm/ and a recent presentation: https://youtu.be/GsFO4ZQlYS8 (this is Shay Gueron who worked on AES-GCM-SIV too).
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
Turns out the people who wrote the in house Go library didn't have any idea. There is no non-deterministic encryption function because that might be too complicated for non-senior engineers (afterall they wrote most of the actual application) to correctly choose.
The first version use AES-CFB. There's no authentication. It's probably copy pasted from a public Gist and nobody ever commented on it that it is insecure. I wonder if it was actually intended to be the non-deterministic version, but the higher level wrappers do not wrap this function so people didn't actually use it.
The second version use AES-GCM with nonce derived from the key and AD. Since nobody understand why AD is needed, AD is always nil. Essentially there's ever one nonce.
I think the problem is that many senior engineers know that encryption use "AES" library but the Go standard library doesn't tell you how to use it securely.
Surprisingly this mistake also happen in our Java stack that was written by a different team. A senior engineer did notice and quietly moved away from the vulnerable version without telling the Go version.
I wrote a POC to decrypt data of the Go version, then wrote the third version, perhaps it will be open source soon. The new library only implement envelope key management, encrypted string wrapper and ORM integration. The rest is Google's Tink.
"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.
Earlier quoted context omitted.
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 cons…
I dunno, nonce means number-used-once, it should be kinda obvious that it should be used only once?
Also, it's not entirely clear just how bad a reuse actually is. For example, in AES-CBC, reusing the IV has much less impact than reusing the nonce with AES-GCM.
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…
I don't think nonces bigger than 12 bytes will help. My quick reading of the AES-GCM spec is that when using a nonce that's not 96 bits (12 bytes), it is hashed to 96 bits. So either the nonce (called iv in the spec) is carefully constructed from a counter and set to exactly 96 bits, or the number of invocations is limited. The spec still restricts use of a key to 2^32 total uses for random nonces of any bigger length (resulting in a re-use probability of about 1e-10):
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpubli...