RFR: 8255557: Decouple GCM from CipherCore [v4]

[Anthony Scarpino]

On Fri, 21 May 2021 02:03:56 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix perf problem by reorganizing doLastBlock()
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1515:
> 
>> 1513:             // the dst buffer is too short.  Context will be restored so the
>> 1514:             // method can be called again with the proper sized dst buffer.
>> 1515:             if (len > dst.remaining()) {
> 
> We should check the dst capacity in the beginning of the method, if its capacity is too small, i.e. less than the overall length - tag length, don't proceed further.
> As in the doFinal() w/ byte[] arguments, I am not sure if the save/restore is really necessary.
> Maybe add a test if it's not already covered by existing tests if time permits.

I think it can be moved up without doing any extra work
I'm pretty sure there is a test because I remember Sean C working on a bug with restoring when dst was too small.

> src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 221:
> 
>> 219: 
>> 220:         store("AES/GCM", KnownOIDs.AES_128$GCM$NoPadding,
>> 221:             "AES/GCM/NoPadding");
> 
> In SunJCE class, the registration is done using "AES/GCM/NoPadding" instead of "AES/GCM". I am not sure why is this store() call using AES/GCM is necessary?

I will double check this, but I believe this change and the need for AESGCM in SunJCE are linked together

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072