Re: [TLS] Consensus call on Implicit IV for AEAD

[Yoav Nir <[e-mail]>]

> On Apr 6, 2015, at 2:25 PM, Tom Ritter <[e-mail]> wrote:
> 
> On 6 April 2015 at 03:41, Yoav Nir <[e-mail]> wrote:
>> So either IVs (actually nonces) are compressible only for such ciphersuites that support using the record counter as nonce/IV (add a flag to the registry), or else we use some method such as AGL's for generating unpredictable IVs from predictable nonces.
> 
> 
> Thanks Yoav, ekr,
> 
> I obviously haven't followed all the arguments here (and from skimming
> Brian's reply) - but I prefer defining a construction that makes the
> IV given to the AEAD unpredictable and random. Doing that from a
> predictable nonce seems okay.

That depends. AES-GCM accepts a 64-bit IV. ChaCha20-Poly1305 is the same. If you feed it random bitstrings, you’re very likely to repeat a bitstring after a few billion records, and you have a good chance of repeating the IV even after many fewer records. So it’s much better to use a counter or 64-bit LFSR, even though they’re predictable. With a function that receives a 128-bit IV such as AES-CBC, randomization is fine. 

A good way for both is to encrypt a counter with a secret key (whether shared with the other side and then you can omit the IV or not and then you need to include it), but using a 64-bit cipher (DES?) to generate random-looking, non-repeating nonces for AES-GCM seems like a very weird idea.

So I’d rather have a nonce, and require whoever defines an AEAD based on CBC mode to either add an IV to the payload or define a way to calculate a non-predictable IV from that nonce.

Yoav