On Fri, 28 Oct 2022 21:03:32 GMT, vpaprotsk <d...@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
