Re: aes128gcm: why verify padding?

[Ilari Liusvaara <[e-mail]>]

On Mon, Jan 23, 2017 at 04:28:55AM +0000, Manger, James wrote:
> After implementing aes128gcm I have another reason to adjust the
> padding scheme. Putting the content first, before the padding
> (whatever format), will save moving the content after decryption
> in some (typical?) implementations. A Decrypt API will typically
> expect the content to be at the start of a given buffer. For
> instance, my implementation decrypts to a given buffer, but due
> to the current padding scheme (<padlen><padding><content>) then
> needs to copy the data to the start of the buffer (shifting it 2
> bytes backwards in typical no-padding situations). If, instead,
> the content came first then the data wouldn't need to be moved.
> 
> 
> So I would support a padding scheme similar to TLS 1.3:
> <content><non-zero byte><zeros…>.

Furthermore, if the nonzero byte was 0x01 for non-final blocks and
0x81 for final block (or any two different nonzero values), then
that would also solve the truncation flaw from last message, no?

And while we are at breaking things, it would be good time to make
rs count ciphertext, not plaintext, right?



-Ilari