(no title)
redfast00 | 1 year ago
> The solution they designed is described in that linked paper: AES-GCM-SIV, which is able to tolerate some number of nonce collisions, but under a weaker notion of security that is only really applicable to that use-case (where the data being encrypted is itself random).
AES-GCM breaks catastrophically if you reuse a nonce; but the only thing that happens if you reuse a nonce with AES-GCM-SIV for two messages is that an attacker can see if the messages are equal (since AES-GCM-SIV is a deterministic algorithm, this is pretty much unavoidable). So yes, "weaker notion of security", but still applicable to a lot more than just that use-case. I wonder why AES-GCM-SIV is not used more, since it's so developer-friendly and misuse resistant.
nmadden|1 year ago
Being able to see if two messages are equal means that it doesn’t even achieve IND-CPA security (when nonces repeat). Although this may seem like a small loss of security, it can have significant consequences. For example, when you are performing encryption of long messages, you generally want to split them into smallish chunks -- otherwise you’ll likely have to release unverified plaintext during decryption unless you buffer the entire message in memory. But now if your AEAD reveals message equality, like AES-GCM-SIV does under nonce reuse, then an attacker can see when chunks are equal if you are not careful. So you can end up vulnerable to the kind of chosen plaintext attacks that are devastating against ECB encryption.
Phillip Rogaway, co-inventor of the original SIV mode and the MRAE security model, discusses BEAST-style chosen plaintext attacks against online encryption modes using MRAE schemes in https://eprint.iacr.org/2015/189.pdf. As he says in that paper: "The paper defining MRAE never suggested that nonce-reuse was OK.” It leads to security weaknesses, and AES-GCM-SIV has increasing likelihood of nonce reuse after 2^32 messages.
So, yes, AES-GCM-SIV is a lovely piece of work, but if you want to encrypt large numbers of messages with a single key, then you need to be very aware of the security definitions. I wouldn’t recommend it for general use.
lifthrasiir|1 year ago
While I agree on your cautions, this is still an exceptionally large number. Also AFAIK the actual bound depends on the message size, e.g. you can "safely" encrypt 2^64 messages of ~128 KiB each with the identical key but random nonce. So as long as one keep using as random nonce as possible but allowing for a few exceptional reuses, casual developers indeed have a very low chance to actually reach that threshold.
bjoli|1 year ago
Could it be extended in a similar way to be more like xchacha with 192 bit nonces where using random nonces are easier?