W3C home > Mailing lists > Public > public-xmlsec@w3.org > January 2010

RE: Proposal for adding AES-GCM to XML Encryption 1.1

From: Martin, Cynthia E. <cemartin@mitre.org>
Date: Tue, 5 Jan 2010 19:01:35 -0500
To: Frederick Hirsch <Frederick.Hirsch@nokia.com>
CC: ext Pratik Datta <pratik.datta@oracle.com>, XMLSec WG Public List <public-xmlsec@w3.org>, "Martin, Cynthia E." <cemartin@mitre.org>
Message-ID: <6A913BB6ED2E2C43AC275462A83E68490C12521E40@IMCMBX3.MITRE.ORG>
Yes it is.

Regards, Cynthia


-----Original Message-----
From: Frederick Hirsch [mailto:Frederick.Hirsch@nokia.com] 
Sent: Thursday, December 10, 2009 10:04 AM
To: Hirsch Frederick (Nokia-CIC/Boston)
Cc: ext Pratik Datta; Martin, Cynthia E.; XMLSec WG Public List
Subject: Re: Proposal for adding AES-GCM to XML Encryption 1.1

Is this  the correct AES-GCM reference?

M. Dworkin
Recommendation for Block Cipher Modes of Operation: Galois/Counter  
Mode (GCM) and GMAC
NIST Special Publication 800-38D
November, 2007
URI:  http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf

regards, Frederick

Frederick Hirsch
Nokia



On Dec 10, 2009, at 9:58 AM, Hirsch Frederick (Nokia-CIC/Boston) wrote:

> Clarification comments/questions  inline
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Dec 8, 2009, at 3:16 PM, ext Pratik Datta wrote:
>
>> I did a little more investigation on Java crypto libraries and found
>> out that  Padding is usually not supported with AES-GCM.  Unlike AES-
>> CBC, which needs padding, AES-GCM doesn't need padding even though
>> AES-GCM is a block cipher. Also Java crypto libraries place the
>> authentication tag at the end.  I suppose other crypto libraries
>> will do similar things. Based on that here is the revised proposed
>> text.
>>
>> Section 5.1,  (add this to the list of algorithms.)
>>
>> http://www.w3.org/2009/xmlenc11#aes128-gcm
>> http://www.w3.org/2009/xmlenc11#aes256-gcm
>>
> Specifically, add to list of Block Encryption ciphers as Optional, as
> follows:
>
> 5. Optional AES128-GCM
> http://www.w3.org/2009/xmlenc11#aes128-gcm
> 6. Optional AES256-GCM
> http://www.w3.org/2009/xmlenc11#aes256-gcm
>
>>
>> Section 5.2.3 AES-GCM   (add new section)
>>
>
> 5.2.4 (already have 5.2.3), but identifiers at beginning, flagged as
> optional
>
> Identifier:
> http://www.w3.org/2009/xmlenc11#aes128-gcm (Optional)
> http://www.w3.org/2009/xmlenc11#aes256-gcm (Optional)
>
>> AES-GCM is an authenticated encryption mechanism. I.e. it is
>> equivalent to doing these two operations in one step - HMAC signing
>> followed by
>
> i.e.
>> AES-CBC encryption. It is very attractive from performance point of
>> view, because the cost of AES-GCM is similar to regular AES-CBC
>> encryption, yet it achieves the same result as encryption + HMAC
>> signing.. Also AES-GCM can be pipelined so it is amenable to
>> hardware acceleration..
>
> s/.././
>>
>> Identifiers.
>> http://www.w3.org/2009/xmlenc11#aes128-gcm
>> http://www.w3.org/2009/xmlenc11#aes256-gcm
>>
>
> at beginning
>>
>> AES-GCM is used with a 96 bit Initialization Vector (IV), and a 128
>> bit Authentication Tag (T). The cipher text contains the IV first,
>> followed by the encrypted octets and finally the Authentication tag.
>> No padding should be used during encryption. During decryption the
>> implementation should compare the authentication tag computed during
>> decryption with the specified Authentication Tag, and fail if they
>> don't match.
>>
>>
>
> do we have an example?
>
>> Pratik
>>
>>
>> From: Pratik Datta
>> Sent: Monday, November 16, 2009 9:29 AM
>> To: Martin, Cynthia E.
>> Cc: Frederick Hirsch; XMLSec WG Public List
>> Subject: Re: Proposal for adding AES-GCM to XML Encryption 1.1
>>
>> Cynthia/Magnus,
>>
>> Here are some decisions that I took for the AES-GCM.
>> 	* IV Size: The algorithm is simplest with a 96 bit IV, so I decided
>> to go with a 96 bit IV
>> 	* Authentication tag Size: The algorithm supports many different
>> tag sizes, but I decided to go with 128 bit, since that is what TLS
>> chose.
>> 	* Location of Authentication tag: I considered these three options
>> 		* putting it at the end : The end of the ciphertext has the
>> padding, and if I put the Authentication tag in the end, it might
>> make it harder to implement the padding
>> 		* putting it at the beginning : This is what I went for, but
>> streamability is adversely affected with this solution, because
>> during encryption you can compute the authentication tag only after
>> encrypting the whole data, but then you would have to go back to put
>> in the authentication tag in the beginning of the cipherText
>> 		* putting it as a separate tag : this would change the schema, and
>> it is not worth doing that. That would just make it harder for
>> implementations.
>>
>>
>> Pratik
>>
>> On 11/10/2009 5:51 AM, Martin, Cynthia E. wrote:
>> I have no objections- I can review it this morning.
>>
>> Cynthia
>>
>> ________________________________________
>> From: public-xmlsec-request@w3.org [public-xmlsec-request@w3.org] On
>> Behalf Of Frederick Hirsch [Frederick.Hirsch@nokia.com]
>> Sent: Tuesday, November 10, 2009 8:38 AM
>> To: ext pratik datta
>> Cc: Frederick Hirsch; XMLSec WG Public List
>> Subject: Re: Proposal for adding AES-GCM to XML Encryption 1.1
>>
>> Does anyone object to adding this as optional to the XML Encryption
>> 1.1 specification before Last Call?
>>
>> Who can review the text Pratik sent?
>>
>> regards, Frederick
>>
>> Frederick Hirsch
>> Nokia
>>
>>
>>
>> On Nov 9, 2009, at 6:13 PM, ext pratik datta wrote:
>>
>>
>> It will be optional.
>>
>> At this point I am not in a position to interop with this, but maybe
>> in
>> a few months.
>>
>> Pratik
>>
>> On 11/9/2009 12:25 PM, Frederick Hirsch wrote:
>>
>> Pratik
>>
>> Are you proposing we add it as an Optional or Required to implement
>> algorithm?
>>
>> Who is  in a position to interop test this?
>>
>> regards, Frederick
>>
>> Frederick Hirsch, Nokia
>> Chair XML Security WG
>>
>>
>>
>> On Nov 9, 2009, at 3:18 PM, ext pratik datta wrote:
>>
>>
>> I am not sure how important AES-GCM is, but  we can consider
>> adding it
>> to XML Encryption 1.1.
>>
>> NSA suite B requires AES-GCM as a TLS Cipher suite. (see RFC 5430
>> http://www.rfc-archive.org/getrfc.php?rfc=5430)
>>
>>
>>
>> Here is a preliminary proposal for adding AES-GCM (I had a brief
>> discussion about GCM with Brian in the F2F)
>>
>>
>> Section 5.1,  (add this to the list of algorithms.)
>>
>> http://www.w3.org/2009/xmlenc11#aes128-gcm
>> http://www.w3.org/2009/xmlenc11#aes256-gcm
>>
>>
>> Section 5.2.3 AES-GCM   (add new section)
>>
>> AES-GCM is an authenticated encryption mechanism. I.e. it is
>> equivalent
>> to doing these two operations in one step - HMAC signing followed by
>> AES-CBC encryption. It is very attractive from performance point of
>> view, because the cost of AES-GCM is similar to regular AES-CBC
>> encryption, yet it achieves the same result as encryption + HMAC
>> signing.. Also AES-GCM can be pipelined so it is amenable to
>> hardware
>> acceleration..
>>
>> Identifiers.
>> http://www.w3.org/2009/xmlenc11#aes128-gcm
>> http://www.w3.org/2009/xmlenc11#aes256-gcm
>>
>>
>> AES-GCM is used with a 96 bit Initialization Vector (IV), and a
>> 128 bit
>> Authentication Tag (T). The cipher text contains the IV first,
>> followed
>> by the T and then finally the encrypted octets. Decryption should
>> fail
>> if the authentication tag computed during decryption does not
>> match the
>> specified Authentication Tag.
>>
>>
>>
>>
>> Pratik
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
Received on Wednesday, 6 January 2010 00:02:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 6 January 2010 00:02:11 GMT