On Thu, 24 Nov 2022 18:42:01 GMT, Jatin Bhateja <jbhat...@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
