Subject: Re: aes128gcm: is the 1st example wrong?

From: Julian Reschke <[email-masked]>
Date: Sun, 12 Feb 2017 20:47:19 +0100

On 2017-01-17 04:16, Martin Thomson wrote:
> On 17 January 2017 at 15:26, Manger, James
> <[email-masked]> wrote:
>> IKM = B33e_VeFrOyIHwFTIfmesA
>> salt = sJvlboCWzB5jr8hI_q9cOQ
>>
>> Draft gives:
>> PRK = MLAQxt_DHjM15cdlyU1oUnjq7TFlzToGTkdRmvvxVBw
>>
>> But I get:
>> PRK = Mg9ErPx3DpJfkz72kj7Yvx369iqvd4Fmf7tOMTdXELo
>
> Ahh, so do I.  Strange.  I ran those examples many times.  And I even
> have unit tests against them....
>
> ...except that the unit test has the key "6Aqf1aDH8lSxLyCpoCnAqg",
> which I expect will work for you.  Fixed it in 622f21d.

FWIW, I was able to reproduce the examples with the updated code in 
<https://gist.github.com/reschke/46659c912b426dffeac41d9a21421c95>, 
modulo the change Martin mentioned (but which I don't see in Git).

WRT 
<https://greenbytes.de/tech/webdav/draft-ietf-httpbis-encryption-encoding-06.html#rfc.section.3.2>: 
it would be good if the prose mentioned that this specifies a keyid of 
"a1" in the header.

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Feb 2017 10:32:29 +1100

On 13 February 2017 at 06:47, Julian Reschke <[email-masked]> wrote:
> <https://gist.github.com/reschke/46659c912b426dffeac41d9a21421c95>, modulo
> the change Martin mentioned (but which I don't see in Git).

'twas on a branch.  I've merged that now.

> it would be good if the prose mentioned that this specifies a keyid of "a1"
> in the header.

Also on said branch :)

---

From: "Manger, James" <[email-masked]>
Date: Sun, 12 Feb 2017 23:41:35 +0000

The padding scheme has also been updated (from <padlen><data><0..> to <data><1|2><0...>). So you need new code, Julian.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, 13 February 2017 10:32 AM
To: Julian Reschke <[email-masked]>
Cc: Manger, James <[email-masked]>; [email-masked]
Subject: Re: aes128gcm: is the 1st example wrong?

Also on said branch :)

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Feb 2017 09:09:59 +0100

> The padding scheme has also been updated (from <padlen><data><0..> to <data><1|2><0...>). So you need new code, Julian.

Ack.

So... where do I get the padding length from under the new format?

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Feb 2017 19:53:02 +1100

> So... where do I get the padding length from under the new format?

You count from the end of the plaintext.  All the zeros are padding.
The first non-zero octet (starting from the end) is the end of the
padding and should be 0x01 (regular) or 0x02 (last record).

---

From: Daurnimator <[email-masked]>
Date: Thu, 16 Feb 2017 12:07:12 +1100

> padding and should be 0x01 (regular) or 0x02 (last record).

Disallowing 8bit data seems undesireable.

---

From: "Manger, James" <[email-masked]>
Date: Thu, 16 Feb 2017 01:11:43 +0000

8bit data is perfectly fine.
All zeros *from the end back to the padding delimiter byte* are padding.
Bytes before the padding delimiter byte can be anything (including zero).

---

From: Daurnimator <[email-masked]>
Date: Thu, 16 Feb 2017 16:55:31 +1100

> Bytes before the padding delimiter byte can be anything (including zero).

Ah sorry, I misunderstood.