Hello Tomas, We have made several improvements recently to the ECC provider implementation in JDK7.
Unfortunately the following low-priority RFE's did not make it and will be evaluated for the next update release: P4 7007966 Add Brainpool ECC support (RFC 5639) P4 7018515 Add SHA224withECDSA in the PKCS#11 wrapper On 05/ 7/11 01:48 AM, Brad Wetmore wrote: > The work I just did was just to provide API support for GCM (and later CCM, > likely in 8). > > We're really ramping down for the JDK 7 release, and I don't know what > Vinnie/Valerie have in mind for the remaining time. > > Brad > > > On 4/27/2011 1:34 AM, Tomas Gustavsson wrote: >> >> Hi, >> >> (changed subject as to not mess up review threads). >> >> Just a question weather this NSA Suite B effort will mean that some >> attention will be given to ECC ciphers and PKCS#11 in JDK 7? >> >> We have a few fix requests submitted in this area. >> >> Regards, >> Tomas >> >> >> On 04/07/2011 06:46 AM, Brad Wetmore wrote: >>> Hi Xuelei/Valerie, >>> >>> Our JDK 7 freeze window is fast closing and I'd like to get this in for >>> b140, so will need a quick turnaround to make this happen. >>> >>> 7031343: Provide API changes to support future GCM AEAD ciphers >>> >>> As we talked about, as part of the National Security Agency's Suite B >>> effort [1] (modernization of the national crypto infrastructure), the >>> JDK will soon need to support the Galois Counter Mode (GCM) cipher mode >>> [2] for ciphers like AES. (e.g. GCM is also being used in some new TLS >>> ciphersuites [3][4]). >>> >>> We will not be able to provide a full implementation of GCM in JDK 7 >>> FCS, but we would like to be able to add this as a potential enhancement >>> in a future JDK 7 Update Release (UR). Adding GCM in an JDK 7 UR will >>> require API changes in JDK 7 now. >>> >>> The changes are fairly small, low risk, and localized. There are some >>> minor changes to Cipher/CipherSpi, and two new classes for an AEAD >>> Exception and a GCMParameterSpec. >>> >>> http://cr.openjdk.java.net/~wetmore/7031343/javadocs.00/ >>> http://cr.openjdk.java.net/~wetmore/7031343/webrev.00/ >>> >>> A few points worth calling out: >>> >>> 1) The API's were designed with an eye to both CCM and GCM. GCM is the >>> important one now from the Suite B perspective. We'll probably add >>> similar CCM Parameters in JDK 8. >>> >>> 2) If algorithm parameters are not derivable from the supplied inputs, >>> Cipher.init() will normally trigger the generation of algorithm >>> parameters based on provider-specific default values. But note that XML >>> GCM is using 128 bit tags, and TLS 1.2 is using 96 bit tags, so there >>> really isn't a completely clear-cut default. And in GCM for IV, that >>> would push IV generation down into the CSP provider, which means the >>> provider must keep track of all previously used IV's, which could be >>> perceived as a 128-bit memory leak for each GCM operation on reused >>> Cipher objects. Language was added to allow providers to select IV if >>> they really want to, but in most cases and for interoperability, the >>> caller really should be specifying the tagLen/IV in a GCMParameterSpec. >>> >>> 3) AEAD (GCM/CCM) tags are appended to the ciphertext on encryption, and >>> verified/removed during decryption, as is done in RFC 5116[5], and is >>> reflected in other GCM APIs. Because Ciphers are reset after each >>> doFinal(), we would have had to create an intermediate state/getTag(), >>> or add some kind of outbound data structure. Appending was far cleaner. >>> >>> 4) AEADBadTagException is a subclass of BadPaddingException, which is a >>> checked exception currently thrown by the doFinal methods. While it's >>> not exactly BadPadding in the true sense of padding, it is close and was >>> the best option for a checked Exception. A RunTimeException really >>> should be reserved for programming mistakes, not normal operations. >>> >>> 5) AAD can be supplied to the cipher in chunks, and is not restricted to >>> a single shot as in PKCS11. This will allow applications with huge AADs >>> the flexibility to not have to store everything in memory (media files). >>> Also, the underlying GCM/CCM algorithms process all AAD before the >>> plain/ciphertext, so we require updateAAD() to be called before >>> plain/ciphertext is handled. >>> >>> 6) As usual for adding new methods to these engine classes, for >>> backwards source and binary compatibility with older providers, the new >>> updateAAD() methods in CipherSpi will throw >>> UnsupportedOperationExceptions unless the provider overrides the method. >>> >>> Thanks, >>> >>> Brad >>> >>> [1]: http://www.nsa.gov/ia/programs/suiteb_cryptography/ >>> [2]: http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf >>> [3]: http://www.rfc-editor.org/info/rfc5288 >>> [4]: http://www.rfc-editor.org/info/rfc5289 >>> [5]: http://www.rfc-editor.org/info/rfc5116
