Subject: [jose] AES-GCM in JWE

From: Mike Jones <[email-masked]>
Date: Fri, 4 May 2012 22:16:21 +0000

In the current JWE spec<http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01>, AES Galois Counter Mode (GCM) is treated quite differently than other algorithms because it provides an integrated integrity check, however some of the unique properties of GCM are not utilized.  Having more deeply investigated the actual GCM specification (NIST SP800-38D) and implementations, I now believe that its treatment can and should be much more like the other algorithms in JWE.  Specifically, the current JWE spec is silent on how to use these properties GCM:

*        GCM includes an "additional authenticated data" parameter, in addition to the plaintext

*        GCM specifies a preferred IV length of 96 bits (12 bytes)

*        GCM has a separate "authentication tag" output, distinct from the ciphertext output

In the next version of the JWE spec, I plan to specify that the GCM "additional authenticated data" input for GCM be the concatenation of the Encoded JWE Header, a period ('.') character, and the Encoded JWE Encrypted Key.  This will then include these values in the GCM integrity value calculation, just as they are included in the separate integrity value calculation<http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-9> of JWE for non-AEAD algorithms (thus securing the header and encrypted key values).

Likewise, in the next version of the JWE spec, I plan to specify that the GCM "authentication tag" output be base64url encoded and used as the Encoded JWE Integrity Value (the fourth field of the JWE), just as the separately computed integrity value is used as the Encoded JWE Integrity Value for non-AEAD algorithms.

Finally, in the next version of the JWE spec, I plan to specify that a 96 bit IV be used with GCM.

This will make the treatment of GCM substantially more parallel to non-AEAD algorithms and will use the "additional authenticated data" feature of GCM to secure the encryption parameters, as I believe was its intended use.

                                                            -- Mike

P.S.  My thanks to Edmund Jay for his deep dive into the particulars of GCM in the course of his JWE implementation work.

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 4 May 2012 16:00:11 -0700

+1

=nat via iPhone

On 2012/05/04, at 15:16, Mike Jones <[email-masked]> wrote:

  In the current JWE
spec<http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01>,
AES Galois Counter Mode (GCM) is treated quite differently than other
algorithms because it provides an integrated integrity check, however some
of the unique properties of GCM are not utilized.  Having more deeply
investigated the actual GCM specification (NIST SP800-38D) and
implementations, I now believe that its treatment can and should be much
more like the other algorithms in JWE.  Specifically, the current JWE spec
is silent on how to use these properties GCM:

·        GCM includes an “additional authenticated data” parameter, in
addition to the plaintext

·        GCM specifies a preferred IV length of 96 bits (12 bytes)

·        GCM has a separate “authentication tag” output, distinct from the
ciphertext output

In the next version of the JWE spec, I plan to specify that the GCM
“additional authenticated data” input for GCM be the concatenation of the
Encoded JWE Header, a period ('.') character, and the Encoded JWE Encrypted
Key.  This will then include these values in the GCM integrity value
calculation, just as they are included in the separate integrity value
calculation<http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-9>of
JWE for non-AEAD algorithms (thus securing the header and encrypted
key
values).

Likewise, in the next version of the JWE spec, I plan to specify that the
GCM “authentication tag” output be base64url encoded and used as the Encoded
JWE Integrity Value (the fourth field of the JWE), just as the separately
computed integrity value is used as the Encoded JWE Integrity Value for
non-AEAD algorithms.

Finally, in the next version of the JWE spec, I plan to specify that a 96
bit IV be used with GCM.

This will make the treatment of GCM substantially more parallel to non-AEAD
algorithms and will use the “additional authenticated data” feature of GCM
to secure the encryption parameters, as I believe was its intended use.

                                                            -- Mike

P.S.  My thanks to Edmund Jay for his deep dive into the particulars of GCM
in the course of his JWE implementation work.

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: John Bradley <[email-masked]>
Date: Mon, 7 May 2012 11:07:22 -0400

+1
I looked at this with Mike and Edmund.  Some of the changes are necessary for interop, as GCM was underspecified.  Keeping the input and output parameters in line with there handling in CBC + HMAC makes the spec more consistent.

John B.
On 2012-05-04, at 7:00 PM, Nat Sakimura wrote:

>> In the current JWE spec, AES Galois Counter Mode (GCM) is treated quite differently than other algorithms because it provides an integrated integrity check, however some of the unique properties of GCM are not utilized.  Having more deeply investigated the actual GCM specification (NIST SP800-38D) and implementations, I now believe that its treatment can and should be much more like the other algorithms in JWE.  Specifically, the current JWE spec is silent on how to use these properties GCM:
>> ·        GCM includes an “additional authenticated data” parameter, in addition to the plaintext
>> ·        GCM has a separate “authentication tag” output, distinct from the ciphertext output
>>  
>> In the next version of the JWE spec, I plan to specify that the GCM “additional authenticated data” input for GCM be the concatenation of the Encoded JWE Header, a period ('.') character, and the Encoded JWE Encrypted Key.  This will then include these values in the GCM integrity value calculation, just as they are included in the separate integrity value calculation of JWE for non-AEAD algorithms (thus securing the header and encrypted key values).
>>  
>> Likewise, in the next version of the JWE spec, I plan to specify that the GCM “authentication tag” output be base64url encoded and used as the Encoded JWE Integrity Value (the fourth field of the JWE), just as the separately computed integrity value is used as the Encoded JWE Integrity Value for non-AEAD algorithms.
>>  
>> This will make the treatment of GCM substantially more parallel to non-AEAD algorithms and will use the “additional authenticated data” feature of GCM to secure the encryption parameters, as I believe was its intended use.
>>  
>>                                                             -- Mike
>>