Mailing-List: contact dev-help@santuario.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@santuario.apache.org
Received-SPF: pass (athena.apache.org: domain of putmanb@georgetown.edu
 designates 209.85.220.45 as permitted sender)
Message-ID: <537D3F12.4080903@georgetown.edu>
Date: Wed, 21 May 2014 20:04:34 -0400
From: Brent Putman <putmanb@georgetown.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: dev@santuario.apache.org
Subject: AES GCM and Java 8
Content-Type: multipart/alternative;
 boundary="------------040000020309000600090700"

This is a multi-part message in MIME format.
--------------040000020309000600090700
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

--------------040000020309000600090700
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi,<br>
    For our next major release of OpenSAML, we were doing some testing
    around the use of AES GCM for XML encryption.&nbsp; It seems to work ok
    using the Bouncy Castle provider.<br>
    <br>
    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.&nbsp; Avoiding the need to install BC is seen as
    desirable for our OpenSAML and Shibboleth deployers.<br>
    <br>
    However we have uncovered a problem with the use of Java 8.&nbsp; The
    current XMLCipher code unconditionally passes an instance of
    javax.crypto.spec.IvParameterSpec to the Cipher instance used.&nbsp; BC
    seems to like and want this.&nbsp; However, Oracle's provider fails with:<br>
    <br>
    <tt>java.security.InvalidAlgorithmParameterException: Unsupported
      parameter: javax.crypto.spec.IvParameterSpec@15bbf42f</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; at
      com.sun.crypto.provider.CipherCore.init(CipherCore.java:509)</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; at
      com.sun.crypto.provider.AESCipher.engineInit(AESCipher.java:339)</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; at javax.crypto.Cipher.implInit(Cipher.java:801)</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; at javax.crypto.Cipher.chooseProvider(Cipher.java:859)</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; at javax.crypto.Cipher.init(Cipher.java:1370)</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; at javax.crypto.Cipher.init(Cipher.java:1301)</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; at
org.apache.xml.security.encryption.XMLCipher.encryptData(XMLCipher.java:1129)</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; at
org.apache.xml.security.encryption.XMLCipher.encryptData(XMLCipher.java:1081)</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; at
org.apache.xml.security.encryption.XMLCipher.encryptData(XMLCipher.java:1012)</tt><tt><br>
    </tt><br>
    <br>
    <br>
    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.<br>
    <br>
    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.&nbsp; BC claims that they now support this as Cipher input as of
    their 1.50 release [1]:<br>
    <blockquote type="cite">The JDK 1.5+ provider will now recognise and
      use GCMParameterSpec if it is run in a 1.7 JVM.</blockquote>
    <br>
    The actual BC crypto ops seem to work ok.&nbsp; However I think they have
    a bug around this: when used with GCMParameterSpec, after encryption
    their Cipher#getIV() returns null.&nbsp; 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.&nbsp; So this currently doesn't just
    transparently work as it should.<br>
    <br>
    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.&nbsp; <br>
    <br>
    Before I spend more time delving into this, I just wanted to see if
    this was on anyone's radar.&nbsp; I don't see anything in Jira about it
    currently. <br>
    <br>
    Thanks,<br>
    Brent <br>
    <br>
    <br>
    [1] <a class="moz-txt-link-freetext" href="http://www.bouncycastle.org/releasenotes.html">http://www.bouncycastle.org/releasenotes.html</a><br>
  </body>
</html>

--------------040000020309000600090700--