RE: aes128gcm: why verify padding?

["Manger, James" <[e-mail]>]

My though experiment was to have a very simply situation: a key and a counter to use as the nonce. To send a message in, say, 3 AEAD parts use nonces  1, 2, 3; to send the next message in, say, 2 parts use nonces 4 & 5; and the next message in 1 part uses nonce 6. As long as records that start a message are flagged (1, 4, & 6 here) and records that end a message are flagged (3, 5, & 6 here) I think this simple scheme can work: a receiver can tell when a bunch of records are an authentic sequence (prefix, suffix, or in the middle); though not when separate sequences are part of the same message without joining them (no start/end flags in between).

Using XOR, instead of +, can still work; but a receiver can only really authenticate from the start.

Using the KDF seems to mean: you know records are part of the same message (same salt); you know a record's position (even if using XOR, not +); you know where the start is so you don't need to distinguish start & middle.

A start/middle/end indicator is necessary for the simplest schemes.
A not-end/end indicator is sufficient for the aes128gcm scheme, thanks to the KDF.
My judgement is that start/middle/end is more generic, with very little extra complexity (but if I'm in the rough so be it).

--
James Manger



-----Original Message-----
From: Martin Thomson [mailto:[e-mail]] 
Sent: Monday, 30 January 2017 2:20 PM
To: Manger, James <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: aes128gcm: why verify padding?

On 30 January 2017 at 13:30, Manger, James
<[e-mail]> wrote:
>> Actually, if you don't use KDF to obtain the nonce base together with
>> the key, attacker can corrupt messages unless you actually verify that
>> the start block is in its proper place.
>
> Is this because the scheme uses Nonce XOR Index (not Nonce + Index)?

Not exactly.  The theoretical attack (if I understood Ilari correctly)
is if you had an explicit nonce on each record.  For instance, the
nonce is the first 12 octets of the ciphertext.  At that point, an
attacker would be more capable of performing interchanging any two
records.

That's different to your concern regarding dropping of some number of
records and producing a valid sequence of records.

Even assuming that you find an input that produces the same key while
allowing you to control the nonce, you would be stuck with the
interesting problem of finding a pattern of records that fit the XOR
pattern. If there were only two records, dropping the first is
trivial.  If there were three records and you wanted to keep two of
them, you have to switch the second and third to fit the pattern,
which would run afoul of the padding delimiter check.

Given that you would know the key at this point, I'd suggest that
constructing a new message would be easier.


> Given 2 valid AEADs, you can get the XOR of their indices but that isn't enough to tell how far apart they are in a sequence. It isn't even sufficient to tell that one comes right before the other. Hence, you really need to get the AEAD marked "start" first (or get the salt from which the "start" record's nonce is derived).

Are you saying that you can feed random data into your oracle until it
accepts two records?  And that you used the same key to generate that
random data?  Assuming those preconditions, I agree that you can get
the XOR of the indices of these records.  But you must have known
those indices because the oracle we're designing only accepts records
at those indices.

Even if you could do what you suggest (with a different oracle
perhaps), I think that you are right in suggesting that that isn't
much use.  You have just won every lottery on the planet in the same
week, and still that information doesn't seem very useful.