Menu
I have been using AES-CBC for encryption and I use a random IV each time I encrypt plain text. As far as I can tell, this is the recommended approach.
I have been looking into AES-GCM / AES-CTR, primarily for the AEAD. I have not yet implemented anything with this but from everything I have read, basically the nonce is just a shorted IV and there is an internal counter that is used for each encryption call. The developer / needs to make sure the nonce changes before the 32 bit counter cycles back, otherwise the same nonce (IV) is potentially used with the same key which could encrypt the same plain text and leak the encryption key.
What I don't really understand is why can AES-CBC be fine with a random IV but some of what I have read indicates a random nonce (IV) for AES-GCM is a bad idea. The only thing I can think of is the that IV for AES-CBC is longer than the nonce for AES-GCM so the likely hood of duplicate nonce is greater for AES-GCM.
I need to encrypt data that is anywhere from a few bytes to 10 - 20 GB. I know AES-GCM has a limit to the size of data (~60GB) that it can encrypt before the counter cycles. I can get around this limitation since my data is below this limit.
Can someone shed some light on why a random nonce is not suggested for AES-GCM?
642
AES-GCM is a more secure cipher than AES-CBC, because AES-CBC, operates by XOR'ing (eXclusive OR) each block with the previous block and cannot be written in parallel. This affects performance due to the complex mathematics involved requiring serial encryption.
The GCM mode uses an initialization vector (IV) in its processing. This mode is used for authenticated encryption with associated data.
From a cryptographic perspective, though, both AES-CBC and AES-GCM are highly secure. GCM provides authentication, removing the need for an HMAC SHA hashing function. It is also slightly faster than CBC because it uses hardware acceleration (by threading to multiple processor cores).
In Cipher Block Chaining (CBC) mode, an initialization vector (IV) is added to the first block of plaintext before encryption and the resultant ciphertext is added to the next block of plaintext before encryption, and so on. Decryption is the reverse process.
GCM is based on CTR mode and inherits the many-time pad (or two-time pad) problem if a nonce is reused with the same key (very nice example). If the IV is reused in CBC mode, then the only thing that an observer can detect is the equality of message prefixes.
An observer can detect that a previously sent message is sent again with CBC mode, which might not give them much, but CTR provides them with the ability to deduce the contents of a message if the some information about the structure of the content is known.
A nonce for AES-GCM mode is expected to be 96 bit long. If you're generating nonces randomly, then you are expected to generate a duplicate nonce after 2n/2=248 messages (see Birthday problem). That is, the probability of generating a duplicate nonce is 50% if you generated 248 encrypted messages with the same key. That is quite a lot of messages, but it can happen earlier.
103
Using a random IV / nonce for GCM has been specified as an official recommendation by - for instance - NIST. If anybody suggests differently then that's up to them.
The birthday problem greatly increases the chance of an IV collision when a random IV is used. With the default size of the nonce (12 bytes or 96 bits) the chance of a collision isn't high. It is still possible to encrypt over a billion files or messages before the mode becomes vulnerable.
If GCM becomes vulnerable then an adversary may find the (internal) key used to generate the authentication tag. Besides that, as GCM uses CTR mode internally, so the confidentiality of the data within the files / messages is likely lost. So if an IV is ever repeated GCM will fail spectacularly.
Careful protocol design and implementation of the random IV are required because of the above limitations and vulnerabilities. It is therefore advisable to use a well tested cryptographic random number generator to generate the values of the IV.
More information on the generation of the IV and the resulting limitations is available in sections 8.2 and 8.3 of the NIST specification SP 800-38D on GCM.
In the NIST specs it is required to use the full 96 bits for the random IV. So there aren't any spare bits to include other information within the IV, as using an IV other than the default size of 96 bits is not advisable.
NIST specifies a limit of of 2^32 (four billion) messages to be encrypted with the same key for the randomly generated IV.
If the number of messages is an issue it might be better to use a key based key derivation algorithm and derive a new AES-256 bit key for each ciphertext. Another option that might offer some security against collisions for the random nonce is using AES-GCM-SIV, as the IV doesn't just rely on the nonce if that's used. Still, you'd need a maximum number of messages even for SIV mode.
27
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
