Re: aes128gcm: vulnerable to truncation attacks

[Martin Thomson <[e-mail]>]

I think that Ilari's recommendation on the other thread also solves
this problem.

On 23 January 2017 at 11:48, Manger, James
<[e-mail]> wrote:
> There is a serious flaw in aes128gcm that allows a message to be truncated
> while authenticated decryption still succeeds.
>
>
>
> aes128gcm produces 1 or more AEAD records, where all but the last match the
> given record size. This allows you to authenticate the end of the stream
> when you receive at least 2 records. But if you only receive 1 record you
> cannot tell if you have a complete message or a truncated message with a
> tampered record size.
>
>
>
> The problem is that the record size in the header is not authenticated.
>
>
>
> For example, the “Encryption with Multiple Records” example in the spec
> consists of the following ciphertext (in base64url), which decrypted to “I
> am the walrus”:
>
>
>
> uNCkWiNYzKTnBN9ji3-qWAAAABoCYTGHOqYFz-0in3dpb-VE2GfBngkaPy6bZus_
>
> qLF79s6zQyTSsA0iLOKyd3JqVIwprNzVatRCWZGUx_qsFbJBCQu62RqQuR2d
>
>
>
> Truncating this ciphertext after the 1st record, and increasing the record
> size field in the header from 26 to 27 gives:
>
>
>
> uNCkWiNYzKTnBN9ji3-qWAAAABsCYTGHOqYFz-0in3dpb-VE2GfBngkaPy6bZus_qA
>
>
>
> This successfully decrypts to “I am th”. It needs to fail, either with an
> authentication failure or a premature end failure.
>
>
>
>
>
> Suggestion: include the record size in the derivation of the key and nonces.
>
> Passing the 20 bytes <16-byte salt><4-byte records size> as the ‘salt’
> parameter of the HKDF Extract call might work. Though putting including the
> record size in the cek_info and nonce_info values that are fed to HKDF
> Expand calls might be even better.
>
>
>
> --
>
> James Manger