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

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

On Thu, 1 Dec 2022 18:41:42 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> 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..)

JMH also added (and main PR comment modified to match)


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

More information about the security-dev mailing list