W3C home > Mailing lists > Public > public-xmlsec@w3.org > November 2009

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

From: pratik datta <pratik.datta@oracle.com>
Date: Mon, 16 Nov 2009 09:28:44 -0800
Message-ID: <4B018BCC.3050607@oracle.com>
To: "Martin, Cynthia E." <cemartin@mitre.org>
CC: Frederick Hirsch <Frederick.Hirsch@nokia.com>, XMLSec WG Public List <public-xmlsec@w3.org>
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
          o 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
          o 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
          o 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, 16 November 2009 17:31:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:44:00 GMT