RE: aes128gcm: why verify padding?

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…>.

James Manger

-----Original Message-----
From: Martin Thomson [] 
Sent: Monday, 16 January 2017 6:09 PM
To: Manger, James <>
Subject: Re: aes128gcm: why verify padding?

On 16 January 2017 at 14:06, Manger, James
<> wrote:
> Improvement 2 is actually much better for this. The "internal" length (padding length) is calculated mod (external length - 2) so it can never be too large.

A better scheme would be to pad with an arbitrary number of zeroes,
then a terminal non-zero value.  That could be at the end, like in
TLS.  It also allows for lower overhead and arbitrary amounts of

But I'd like to hear whether other people think that this is worth fixing.

Received on Monday, 23 January 2017 04:29:46 UTC