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

[Tomas Gustavsson]

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