RE: aes128gcm: why verify padding?

>> I was hoping for an anti-truncation mechanism that didn't depend in a
>> not-completely-obvious-to-me manner on a seemingly quite separate aspect:
>> the KDF. For instance, even with no KDF (for key or nonce) having a byte
>> distinguishing start/middle/end would be sufficient to authenticate you
>> have received an authentic prefix or suffix or complete message.

> 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)?
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).

> This is because if attacker can choose noncebase, attacker can reorder
> the blocks so all decrypt properly.
>
> Using KDF prevents this because attacker can't produce suitably
> related noncebase pairs for the same key

--
James Manger

Received on Monday, 30 January 2017 02:30:51 UTC