2
$\begingroup$

Is there any advantage to using an IV larger than a cipher's block size?

Say I'm using AES-256 in Galois Counter Mode (GCM). My file format looks like this:

[IV] [Ciphertext]

Normally, the IV will be 256 bits, or 32 bytes, if the block size is 256 bits.

Is there any advantage at all in using an IV larger than this, and just splitting it and encrypting it as future blocks in the file?

ie:

# python pseudocode
iv = read(64) # read 64 bytes
cipher = AESGCM256(iv[0:32])
cipher.encrypt(iv[32:64])

block = None

while ((block = read(32) is not None):
    cipher.encrypt(block)

Since the IV is a known value, is there any benefit to having a longer IV and splitting it in this regard? Conversely, is there any flaw in doing it this way?

$\endgroup$
  • 4
    $\begingroup$ the block size of AES-256 is 128-bits. Also GCM has specific rules for IV's larger than 128-bits $\endgroup$ – Richie Frame Nov 17 '15 at 1:51
1
$\begingroup$

No, not as described in the question.

Putting aside the block size confusion that Richie Frame mentions in a comment (AES block size is always 128), there is no advantage to encrypting a second half of an IV in GCM mode in particular, and rarely in other modes.

In GCM mode the actual IV is used to derive a nonce for CTR mode encryption. By adding a block of data in front of the message you only shift the message forward by one block. An attacker can just ignore that block in any attacks they might have on the encryption layer. The extra block also affects authentication, but it should not make the attacker's job any harder since GCM authenticates the ciphertext, which just becomes longer.

Note that GCM actually allows arbitrary length IVs directly. There is, however, not really a benefit to using an IV longer than 128 bits unless it is more convenient for the application in question (it is hashed down to 128 bits anyway). In fact, 96-bit nonces are most efficient (avoiding the hashing step), if you can make sure they are unique.

With e.g. CBC mode the encryption of later blocks depends on the plaintext, so it may seem like encrypting a random block would help. However, the attacker is still faced with an equally difficult problem as the first block of ciphertext effectively becomes the IV: $IV' = E_k(IV_1 \oplus IV_2)$. Here there is some advantage, since predictable (but unique) $IV_1 \oplus IV_2$ would result in an unpredictable $IV'$, and CBC requires unpredictable IVs. However, it would be better to just use an encrypted counter if you do not have a good source of random IVs.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.