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

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 Thursday, 10 December 2009 14:58:55 UTC