RE: aes128gcm: why verify padding?

A padding byte to distinguish intermediate and final records could indeed work.

It doesn't consume any extra bytes in this scheme as it piggy-backs on an end-of-padding byte. But in a different multiple-AEAD-record scheme that didn't offer padding (a nice, but not strictly necessary feature) it wouldn't be so ideal. I've seen ideas to put the first-vs-intermediate-vs-last indicator in the nonce, in the KDF, in the AAD, in the record length, and now in the plaintext. I'm not sure how to pick.

What do you do if last non-zero byte isn't 0x01 or 0x02?

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

That's already in the editor's draft (https://github.com/httpwg/http-extensions/blob/master/draft-ietf-httpbis-encryption-encoding.md).

--
James Manger

-----Original Message-----
From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] 
Sent: Monday, 23 January 2017 6:36 PM
To: Manger, James <James.H.Manger@team.telstra.com>
Cc: Martin Thomson <martin.thomson@gmail.com>; ietf-http-wg@w3.org
Subject: Re: aes128gcm: why verify padding?

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

Received on Monday, 23 January 2017 12:48:21 UTC