On Thu, 26 Nov 2020 02:14:40 GMT, Anthony Scarpino <ascarp...@openjdk.org>
wrote:
>> 8253821: Improve ByteBuffer performance with GCM
>
> Anthony Scarpino has updated the pull request incrementally with five
> additional commits since the last revision:
>
> - test updates
> - test check mixup
> - Overlap protection
> - Updated code comments, all tests pass
> - Updated code comments, all tests pass
src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line
910:
> 908: // Decrypt the all the input data and put it into dst
> 909: doLastBlock(buffer, ct, dst);
> 910: dst.limit(dst.position());
Based on Cipher javadoc, the output buffer's limit should remain the same, just
its position be advanced by the number of bytes written into it. So, we should
not call limit(int) to set a new limit on user-specified ByteBuffer objects.
src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line
1000:
> 998: tmp.position(dst.position());
> 999: bb.put(tmp);
> 1000: bb.flip();
Since we don't need to read the content of output buffer, I suppose we can just
do ByteBuffer.allocate(dst.remaining())?
src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line
935:
> 933: */
> 934: ByteBuffer overlapDetection(ByteBuffer src, ByteBuffer dst) {
> 935: if (src.isDirect() && dst.isDirect()) {
originalDst is only set to null at construction time. It should be reset here
or in restoreDst(). Otherwise, there may be some strange interaction between
various ByteBuffer calls using the same Cipher object. Say, the first call uses
an extra copy and set originalDst, then the second call does not, but
originalDst is still non-null.
-------------
PR: https://git.openjdk.java.net/jdk/pull/411
