ECC RFE's (was: Re: NSA Suite B ciphers and JDK7, i.e. review 7031343)

[Vincent Ryan]

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