Sorry for the late comment - You might want to consider section 9.1, first paragraph of SP800-38D which defines the GCM mode. Basically, for FIPS validated implementations, to prevent accidental reuse, the IV needs to be generated inside the cryptographic boundary using one of the defined mechanism. Obviously, that's on the ENCRYPT side since you need to match the IV on the DECRYPT side.
I think you may need to add a GCMParameterSpec that allows you to specify either the IV or the IV length as a subclass of IvParameterSpec. Mike At 08:23 PM 12/7/2012, Valerie (Yu-Ching) Peng wrote: >Max, > >The webrev has been updated so that different key + iv values have to be used >for AES/GCM encryption. >Latest version at: http://cr.openjdk.java.net/~valeriep/6996769/webrev.03/ > >Please review and send me comments. >Thanks! >Valerie > >On 11/07/12 21:50, Valerie (Yu-Ching) Peng wrote: >>Max, >> >>Update: I removed the block (starting line 580 in CipherCore.java) for >>handling RC2 since it's never used. >> >>It turns out that the current impl in RC2Cipher always convert the >>AlgorithmParameters object to RC2ParameterSpec and only uses >>CipherCore.init(..., AlgorithmParameterSpec,...) method. Thus, I won't be >>adding a regression test, but rather simply document the current RC2Cipher >>behavior in CipherCore.java to clarify things up. >> >>The updated webrev is at: >>http://cr.openjdk.java.net/~valeriep/6996769/webrev.01/ >> >>Xuelei brought up the issue of enforcing (Key+IV) uniqueness for GCM mode >>during this afternoon's meeting. >>I think more changes may be made after we decide what to do. >>So, there may be a webrev.02 coming... Just a heads up. >> >>Thanks! >>Valerie >> >>On 11/07/12 14:48, Valerie (Yu-Ching) Peng wrote: >>>>580 } else if (key.getAlgorithm().equals("RC2")) { >>>> >>>>This seems a bug fix. Is there a regression test for it? >>>I just noticed this problem when make the enhancement for GCM mode. >>>I will add a regression test for this.
