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

I agree that's a good reference for the GCM mode.

-- Magnus


> -----Original Message-----
> From: public-xmlsec-request@w3.org [mailto:public-xmlsec-
> request@w3.org] On Behalf Of Frederick Hirsch
> Sent: Monday, December 14, 2009 6:28 AM
> To: ext Pratik Datta; XMLSec WG Public List; Cynthia E. Martin
> Cc: Hirsch Frederick (Nokia-CIC/Boston)
> Subject: Revised Proposal for adding AES-GCM to XML Encryption 1.1
> 
> Does the WG agree to incorporate the proposal as modified here (below)
> into the XML Encryption 1.1, as well as the following 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 Monday, 14 December 2009 16:51:23 UTC