Re: [TLS] ChaCha and IVs

[Adam Langley <[e-mail]>]

Here are the points from the slides:

> From a security assurance perspective,
> an IV based on a protocol-supplied value
> expands the scope of what has to be
> analyzed (to ensure uniqueness)

The uniqueness of the sequence number is needed to ensure that records
cannot be reordered so you cannot get away from having to establish
that property.

> An algorithm implementation submitted for FIPS evaluation must be independently evaluable.

An evaluation already assumes properties - i.e. that the key is
actually secret! The interface and assumptions of an AEAD are well
established (https://tools.ietf.org/html/rfc5116) and include an nonce
input that must be unique for a given key.

> If DTLS and ESP adopt different IV approaches for the
> same algorithm/mode, chip vendors have problems

ChaCha is not the hardware orientated cipher in any case, but I'm
unconvinced this is true. So far, hardware implementations that I've
seen take the nonce as an input, which is also the obvious design from
my point of view.

> In some cases, a non-counter IV approach can be faster
> than a counter (in hardware)

A non-counter IV is not safe unless the nonce is significantly
extended. Certainly, nobody should never use a non-counter IV with
AES-GCM in TLS. In any case, I think significant evidence would be
needed to show that the performance of this outweighs the cost of
wasting ~16 bytes / record.

> Allowing each sender to choose its own IV generation
> approach is more flexible.

It's flexible in the same way that AES-GCM in TLS is flexible: i.e.
that I had to survey all the implementations to ensure that nobody has
used a random IV because that's unsafe. I don't want that sort of
flexibility!


Cheers

AGL