RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions [v5]
Jamil Nimeh
jnimeh at openjdk.org
Fri Oct 28 21:58:30 UTC 2022
On Fri, 28 Oct 2022 21:03:32 GMT, vpaprotsk <duke at openjdk.org> wrote:
>> I think I will remove the check for now, dont want to hold up reviews. I wasn't sure how to 'inject a backdoor' to the commented out check either, or at least how to do it in an acceptable way. Your ideas do sound plausible, and if anyone does want this check, I can implement one of the ideas (package private boolean flag? turn it on in the test) while waiting for more reviews to come in.
>>
>> The comment about ChaCha being the only way in is also relevant, thanks. i.e. this is a private class today.
>
> I flipped-flopped on this.. I already had the code for the exception.. and already described the potential fix. So rather then remove the code, pushed the described fix. Its always easier to remove the extra field I added. Let me know what you think about the 'backdoor' field.
Well, what you're doing achieves what we're looking for, thanks for making that change. I think I'd like to see that value set on construction and not be mutable from outside the object. Something like this:
- place a `private final boolean checkWeakKey` up near where all the other fields are defined.
- the no-args Poly1305 is implemented as `this(true)`
- an additional constructor is created `Poly1305(boolean checkKey)` which sets `checkWeakKey` true or false as provided by the parameter.
- in setRSVals you should be able to wrap lines 296-310 inside a single `if (checkWeakKey)` block.
- In the Poly1305KAT the `new Poly1305()` becomes `new Poly1305(false)`.
-------------
PR: https://git.openjdk.org/jdk/pull/10582
More information about the security-dev
mailing list