Re: [TLS] shibboleth and the nonce

[Adam Langley <[e-mail]>]

On Thu, Jul 24, 2014 at 11:21 AM, Martin Thomson
<[e-mail]> wrote:
> As far as I am aware, there are no concrete concerns about implicit
> nonces from a straight-up security perspective.  Is that right?

For polynomial MACs, no. (For CBC mode, yes.)

> The previous response to suggestions that the nonce was a required
> input was to have a counter produce the nonce input, with a matching
> counter and validation in the module.
>
> The new information yesterday was that David McGrew suggested that the
> nonce needed to be arbitrary.  In that case, do we actually need the
> input to be validated?  Does the certification process check that the
> module produces different output for different nonces by starting
> separate module instances with the same values for all other inputs
> (keys, ad, and plaintext) then varying the input nonces?
>
> I'm sure that there are other concerns, but it's hard for me to make
> an assessment based on the information made available thus far.

I'm not sure that I understand David McGrew's reported suggestion here.

I thought that the concern was that the "crypto module" (being the
thing that is validated) needs to ensure that nonces don't repeat
because the security of the system should be a property of the crypto
module alone.

In that case, the module can either generate random nonces itself, or
it can use a counter. In either case, the nonce isn't an input to the
module when encrypting. If it were then, in order to establish
uniqueness, the module would need to remember a list of all previous
nonces.

With AES-GCM, the nonces are explicit which allows the crypto module
to generate them itself and report them to the TLS layer for
transmission. With implicit nonces, the crypto module can use a
counter and the counter keeps in sync with the TLS sequence number.


Cheers

AGL

-- 
Adam Langley [e-mail] https://www.imperialviolet.org