Re: [TLS] ChaCha and IVs

[Nico Williams <[e-mail]>]

On Wed, Mar 5, 2014 at 6:35 PM, Bodo Moeller <[e-mail]> wrote:
> I suppose if this becomes an actual concern for evaluation, you could create
> a more easily evaluable module that accepts explicit IVs but checks that
> these increase monotonically between invocations.  (Accepting *explicit* IVs
> doesn't mean you have to accept *arbitrary* IVs.)

This.

However in the DTLS case there's no way to make the sequence numbers
be monotonic.  What the module could do is keep its own IV sequence
number window and reject the use of sequence numbers that are too old
or reused...

...but note that in the decrypt case it may still be useful to know
that a message is a replay and yet get the authentication tag state
and plaintext outputs.  The GSS-API's GSS_Unwrap() function supports
this.

Having a sequence number window in the algorithm module is a PITA, but
much less a PITA than having to validate all of a TLS implementation.

> (Implicitly, this would also enforce the TLS requirement that sequence
> numbers are not allowed to wrap around once you're beyond 2^64 records.)

And if the IV must initially be randomly chosen, let the module
generate it but let the user (TLS) furnish the sequence numbers to add
to the initial IV to get the actual IV.

Of course, this does mean that on decrypt the algorithm module will
have to output the sequence number/IV.

So this is really an exercise in designing an API to the cipher+mode
that allows the provider to be validated separately from the user
application, and still provide desired assurances to the validator.

Nico
-- T