W3C home > Mailing lists > Public > public-xmlsec@w3.org > June 2012

RE: GCM format question

From: Pratik Datta <pratik.datta@oracle.com>
Date: Wed, 13 Jun 2012 12:46:15 -0700 (PDT)
Message-ID: <7ca65a05-92aa-4cd7-9e7c-12253ef5ca05@default>
To: "Cantor, Scott" <cantor.2@osu.edu>, public-xmlsec@w3.org
Scott,
This was done really to make it easy for Java JCE API users.

In Java JCE API,  there is no mechanism to emit the GCM authentication tag as a side effect of encryption.   Encryption is supposed to input a byte array and output a byte array. 

See http://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html
Notice this line   " This tag is appended to the ciphertext during encryption, and is verified on decryption. "

I was assuming other APIs would do the same to retrofit GCM into existing encryption interfaces which are unaware of authentication tags. That's why we went with this.

Another consideration is streaming. Suppose you are encrypting a very large chunk of data, we want streaming processors to not have to hold on to the encrypted data. That is why we put the authentication tag at the end.   If it were an attribute on CipherValue, then the streaming processor will not be able to emit any encrypted bytes until the whole  encryption is done and the authentication value is computed.

Pratik

-----Original Message-----
From: Cantor, Scott [mailto:cantor.2@osu.edu] 
Sent: Wednesday, June 13, 2012 8:42 AM
To: public-xmlsec@w3.org
Subject: GCM format question

I'm sure there's a good reason, but what is the justification for putting the GCM authentication tag at the end of the ciphertext instead of in an XML attribute or something? It seems very awkward to have to specially handle the ciphertext and split off the tag for just one algorithm. That makes adaptation to existing APIs harder than it needs to be.

-- Scott
Received on Wednesday, 13 June 2012 20:00:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 13 June 2012 20:00:44 GMT