Hi Brent, > Aside from this BC issue, it seems to me that use of GCMParameterSpec is the new "official" provider-independent way this is > supposed to work in Java 7+, and that XMLCipher should support its use.
Yes, that sounds reasonable to me. I guess we are going to need some reflection code here to detect whether GCMParameterSpec is available or not? > Before I spend more time delving into this, I just wanted to see if this was on anyone's radar. I don't see anything in Jira about it currently. No, feel free to submit a patch :-) Colm. On Thu, May 22, 2014 at 1:04 AM, Brent Putman <[email protected]>wrote: > Hi, > For our next major release of OpenSAML, we were doing some testing around > the use of AES GCM for XML encryption. It seems to work ok using the > Bouncy Castle provider. > > We were also hoping to be able to support this in Java 8 without BC, since > at least Oracle's provider now supports AES GCM out-of-the-box. Avoiding > the need to install BC is seen as desirable for our OpenSAML and Shibboleth > deployers. > > However we have uncovered a problem with the use of Java 8. The current > XMLCipher code unconditionally passes an instance of > javax.crypto.spec.IvParameterSpec to the Cipher instance used. BC seems to > like and want this. However, Oracle's provider fails with: > > java.security.InvalidAlgorithmParameterException: Unsupported parameter: > javax.crypto.spec.IvParameterSpec@15bbf42f > at com.sun.crypto.provider.CipherCore.init(CipherCore.java:509) > at com.sun.crypto.provider.AESCipher.engineInit(AESCipher.java:339) > at javax.crypto.Cipher.implInit(Cipher.java:801) > at javax.crypto.Cipher.chooseProvider(Cipher.java:859) > at javax.crypto.Cipher.init(Cipher.java:1370) > at javax.crypto.Cipher.init(Cipher.java:1301) > at > org.apache.xml.security.encryption.XMLCipher.encryptData(XMLCipher.java:1129) > at > org.apache.xml.security.encryption.XMLCipher.encryptData(XMLCipher.java:1081) > at > org.apache.xml.security.encryption.XMLCipher.encryptData(XMLCipher.java:1012) > > > > Some more research showed that Oracle's provider seems to want the new > javax.crypto.spec.GCMParameterSpec introduced in Java 7, for the AES GCM > modes. > > I was preparing to submit a Jira issue and patch for this to XMLCipher, > which conditionally detects whether the algorithm URI was one of the GCM > ones, and produces an instance of GCMParameterSpec instead. BC claims that > they now support this as Cipher input as of their 1.50 release [1]: > > The JDK 1.5+ provider will now recognise and use GCMParameterSpec if it is > run in a 1.7 JVM. > > > The actual BC crypto ops seem to work ok. However I think they have a bug > around this: when used with GCMParameterSpec, after encryption their > Cipher#getIV() returns null. This is used by XMLCipher to get the IV to > concat with the encrypted bytes (see around line 1172). The null here > causes an NPE. So this currently doesn't just transparently work as it > should. > > Aside from this BC issue, it seems to me that use of GCMParameterSpec is > the new "official" provider-independent way this is supposed to work in > Java 7+, and that XMLCipher should support its use. > > Before I spend more time delving into this, I just wanted to see if this > was on anyone's radar. I don't see anything in Jira about it currently. > > Thanks, > Brent > > > [1] http://www.bouncycastle.org/releasenotes.html > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
