RFR: 8253821: Improve ByteBuffer performance with GCM [v3]

Valerie Peng valeriep at openjdk.java.net
Fri Nov 6 23:12:06 UTC 2020


On Thu, 5 Nov 2020 16:51:34 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 514:
>> 
>>> 512:             }
>>> 513:             len -= remainder;
>>> 514:             ibuffer.write(in, len, remainder);
>> 
>> Any chance that 'ibuffer' already contains earlier buffered bytes? If 'ibuffer' contains bytes. then these need to be processed before processing 'in' and you can't write the to-be-processed bytes into 'ibuffer' here.
>
> I does not.  CipherCore only sends block sized data, and the ByteBuffer code uses this method during final operations.

Hmm, ok, this is getting obscure and the correctness is depending on the calling pattern. Can we add a check on line 514 to ensure that there is no bytes in ibuffer?

>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 541:
>> 
>>> 539:         throws IllegalBlockSizeException, ShortBufferException {
>>> 540:         checkDataLength(processed, Math.addExact(len, tagLenBytes));
>>> 541: 
>> 
>> Now that encrypt(byte[], int, int, byte[], int) may also store data into 'ibuffer', shouldn't this encryptFinal() method processes bytes in 'ibuffer' before processing 'in'? The check here would also needs to be updated with ibuffer.size()? If this is true, can this be covered in the added regression tests?
>
> This is not an optimized path for bytebuffers and will never have any data in ibuffer.

Hmm, ok, can we add a check on ibuffer size here just to be sure?

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

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


More information about the security-dev mailing list