Thanks Vincent,
As long as the basic support for ECC using PKCS11 works I'm at least a
bit happy. Looking forward for evolution :-)
Cheers,
Tomas
On 05/09/2011 04:48 PM, Vincent Ryan wrote:
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
