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

Valerie Peng valeriep at openjdk.java.net
Mon Nov 2 19:34:06 UTC 2020


On Thu, 22 Oct 2020 20:11:55 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> - I do not understand where the corruption comes from.  The user provides a buffer that output is suppose to be placed into, what could it be corrupting?  The existing tests (SameBuffer, in particular) works fine with this and the ByteBuffer calls.  I spent a lot of time trying to get those same buffer tests to pass.  
>> - It was my expectation that checkOutputCapacity() is making sure all the inOfs ==<> outOfs are going to work. Does that not catch all cases?
>> - outWithPadding" is excessive because it doubles the allocation for every operation followed by a copy to the original buffer, even if the original buffer was adequate.  I'm ok with doing the extra alloc & copy in certain situations, but not everytime.  Can you be more specific what things may fail that we don't already check for in the regression tests?
>
> I wrote a whole new tests to exercise all the buffers with and without offsets.  Hopefully that covers the concern.  The test found 4 bugs..

Well, existing tests may not catch/check all error cases. Especially, in the past, all calls w/ ByteBuffer inputs are converted to calls w/ byte[] inputs. Thus, testing is focused on byte[] scenarios. In addition, since for decryption, internal buffering is done, there may be no test checking if padding bytes are written to the output buffer. Please see my comment follows.

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

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



More information about the security-dev mailing list