RFR: 8297379: Enable the ByteBuffer path of Poly1305 optimizations [v3]

Volodymyr Paprotski duke at openjdk.org
Thu Dec 1 18:48:21 UTC 2022


On Thu, 24 Nov 2022 18:42:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove comment
>
> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 268:
> 
>> 266:         } else {
>> 267:             while (blockMultipleLength > 0) {
>> 268:                 processBlock(buf, BLOCK_LENGTH);
> 
> For native byte buffers, you can pass the buffer address and base.

Spent some time thinking about this one.. Originally, (from the sample you shared) I thought I had to use `Unsafe`, which I don't think is 'safe' to do in a crypto library. After some searching, I found a 'safe' alternative, `sun.nio.ch.DirectBuffer` interface, which would give me the `long address()`.

The problem is that the current java signature for the intrinsic expects a `[]byte` not a long. I could certainly change the existing intrinsic (or more likely add a new instrinsic calling existing stub assembly).

I would lean towards not supporting Direct Byte buffers right now. (Also, it doesn't seem like other crypto intrinsics do either. At least GCM does not..)

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

PR: https://git.openjdk.org/jdk/pull/11338



More information about the security-dev mailing list