Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications

[Michael StJohns <[e-mail]>]

On 4/15/2016 1:13 PM, Adam Langley wrote:
> On Fri, Apr 15, 2016 at 9:28 AM, Michael StJohns <[e-mail]> wrote:
>> Is there any other scheme currently in use in our protocols (TLS, IPSEC,
>> etc) that has the property that identical messages under the same key/nonce
>> (or key IV) are encrypted identically?
> I think all encryption schemes have this property if I understand you.
>
> Given a fixed (key, nonce, message), all AEADs should be
> deterministic, i.e. will produce a fixed ciphertext. That includes
> AES-GCM, ChaCha20-Poly1305, AES-CCM etc
>
> For CBC modes, some people consider them to be functions of (key,
> message)→ciphertext, in which case the random IV makes them
> non-deterministic in that model. But if considered to be a function of
> (key, message, IV)→ciphertext then they, too, are deterministic too.

Hi Adam - thanks for the question.

That's not exactly what I mean/meant.  In TLS, the same message (record, 
etc) sent under the same key and IV/NONCE (as produced by the TLS 
PRF/KDF functions or produced randomly) will provide different 
ciphertext based on the fact that the record counter changes with each 
message.  That counter doesn't necessarily have to be part of the 
authenticated data in an AEAD cipher as the nonce formation is somewhat 
external to processing (with the exception of the block counter).

To get the equivalent behavior for AES-GCM-SIV, you need to ensure there 
is some sort of per-message unique mixin (unique within the association 
duration at least) that causes the tag to be different which causes the 
nonce to be different.

*sigh* Let me try it another way.  Take generic AES-GCM, a key and a 
random association nonce.  We form the message nonce from the 
concatenation of the association nonce and a message id or counter. We 
form the block nonce from the concatenation of the message nonce and the 
block counter.  We encrypt the block nonce to provide the data to be 
XOR'd.  The message and AD that we encrypt and protect need not include 
the message id - as long as we can derive it or count it, we don't have 
to send it and it will not be included under the cryptographic 
calculations.  This mostly doesn't matter, because if either end gets 
the counter wrong, the message fails to authenticate at the receiver.

That's not the case for AES-GCM-SIV.  If the message ID is not part of 
the data provided (either payload to be encrypted or associated AD) to 
the POLYVAL function, you will have identical tags for identical 
messages leading to identical ciphertext for identical plain text.

It turns out that this mostly doesn't matter to TLS or IPSEC as they 
both MAC the message sequence number so that's going to be covered by 
any AEAD Associated Data integrity processing and result in a different 
cipher text for the same message even with AES-GCM-SIV. But I remember 
arguments about removing the sequence number in other protocols to save 
space (e.g. its running over TLS - what do we need a sequence number in 
the record for? ) and I worry that this nuance might be missed in future 
protocols that use this cipher mode.


Mike





>
>
> Cheers
>
> AGL
>