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

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
 
 
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 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.
 
 
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: HYPERLINK "mailto:public-xmlsec-request@w3.org"public-xmlsec-request@w3.org [HYPERLINK "mailto:public-xmlsec-request@w3.org"public-xmlsec-request@w3.org] On Behalf Of Frederick Hirsch [HYPERLINK "mailto:Frederick.Hirsch@nokia.com"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