On Fri, 21 May 2021 02:03:56 GMT, Valerie Peng <[email protected]> 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
