On Fri, 13 Nov 2020 20:13:42 GMT, Valerie Peng <valer...@openjdk.org> wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java >> line 518: >> >>> 516: ArrayUtil.nullAndBoundsCheck(out, outOfs, inLen); >>> 517: byte[] block = new byte[blockSize]; >>> 518: int inLenUsed = constructBlock(ibuffer.toByteArray(), in, >>> block); >> >> constructBlock takes 'in' but not 'inOfs'? Wouldn't the data be taken from >> the wrong index? No test catches this, strange? > > The assumption of this whole block here seems to be that ibuffer would not > contain more than a block of buffered data? If that's the case, maybe we can > just use 'ibuffer' instead of allocating a local 'block' and copy the data > into it every time? This is a very seldom used code path, There was only one existing test that accesses this code and it has not offset. constructBlock() is a generic method. There should be no case where ibuffer is >= blocksize during this method. For encryption the two encrypt() only put code in ibuffer. This method is for normal update() operations. The other encrypt is for any of the CipherCore internal buffer needs sent to GCM before doing the doFinal. At that point, ibuffer can be >= blocksize and doFinal will handle it. Some of this complication will go away with phase 2 of separating GCM from CipherCore ------------- PR: https://git.openjdk.java.net/jdk/pull/411
