RFR: 8255557: Decouple GCM from CipherCore [v4]
Anthony Scarpino
ascarpino at openjdk.java.net
Fri May 21 04:50:33 UTC 2021
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
More information about the security-dev
mailing list