Re: aes128gcm: why verify padding?

On 24 January 2017 at 09:10, Manger, James
<James.H.Manger@team.telstra.com> wrote:
> If we go with this approach, we should also distinguish the 1st record. For instance, for the end-of-padding byte:


I think that might be going too far.  Truncating the first record
requires that you are able to find an input to HKDF that provides the
same key, and a nonce that has just the lower bit flipped (you can
truncate more with higher probability).  That requires several
preimage attacks on SHA-256 in series.  Mostly though, marking the
start also increases complexity.  I think that it's enough to say 0x01
= keep going, 0x02 = all done.

Received on Wednesday, 25 January 2017 23:42:34 UTC