santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: AES GCM and Java 8
Date Thu, 22 May 2014 08:34:35 GMT
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 <putmanb@georgetown.edu>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

Mime
View raw message