RE: aes128gcm: why verify padding?

>>>> 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?

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

> I like it.  You can pad an arbitrary amount and you only pay one octet
per record overhead if you don't like padding, and the trailing record
requirement goes away.

If we go with this approach, we should also distinguish the 1st record. For instance, for the end-of-padding byte:
* Set bit 8
* Set bit 1 if this is the first record
* Set bit 2 if this is the last record
0x81 indicates the 1st of multiple records;
0x83 indicates a message with only a single record (first is also last);
0x82 indicates the last of multiple records;
0x80 indicates an intermediate record;
0x00 is padding, keeping looking back for the end-of-padding byte
Any other value indicates an error.

James Manger

Received on Tuesday, 24 January 2017 00:11:38 UTC