Re: [TLS] ChaCha and IVs

[Bodo Moeller <[e-mail]>]

Nico Williams <[e-mail]>:

> Bodo Moeller <[e-mail]> wrote:
>


> > Right -- sorry, when I wrote the above, I only meant a check when
> > *en*crypting. *De*cryption is normally expected to have to handle
> > potentially arbitrary explicit IVs, anyway: for example, if encryption
> uses
> > random IVs, decryption will just have to accept these -- you wouldn't be
> > generating random IVs in the decryption module too :-).
>


> Again, the module might check a sequence number window of its own.
> And on the encryption side you should want a threaded program to be
> able to encrypt out of order.  DTLS' out of order functionality is not
> (or need not be) just in case the transport reorders.


I do understand that, but we have three competing optimization goals here:

- Keep the code requiring FIPS evaluation (if that's required) as small as
possible.
- Avoid the overhead of an explicit IV [as a side-effect, improving
security -- a counter is better than random IVs].
- Allow optimal parallelization.

Pick any two.  For example, if you introduce random IVs to allow concurrent
encryption by multiple threads in a more easily evaluable encryption
module, while encryption can get faster, the explicit IV also means you end
up with more data to send.  It's not clear why that would be the best
trade-off.

Bodo