- From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
- Date: Thu, 10 Dec 2009 10:04:28 -0500
- To: "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com>
- Cc: ext Pratik Datta <pratik.datta@oracle.com>, "Martin, Cynthia E." <cemartin@mitre.org>, XMLSec WG Public List <public-xmlsec@w3.org>
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 Thursday, 10 December 2009 15:05:26 UTC