- From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
- Date: Mon, 14 Dec 2009 09:27:35 -0500
- To: ext Pratik Datta <pratik.datta@oracle.com>, XMLSec WG Public List <public-xmlsec@w3.org>, "Cynthia E. Martin" <cemartin@mitre.org>
- Cc: "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com>
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 14:29:20 UTC