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