NSA Suite B ciphers and JDK7, i.e. review 7031343

[Brad Wetmore]

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