RFR: 8294731: Improve multiplicative inverse for secp256r1 implementation [v2]

[Xue-Lei Andrew Fan]

On Mon, 31 Oct 2022 17:19:21 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>>> BigInteger exponentiation time also depends on also depends on the base; quick benchmark: `BigInteger.ONE.modPow(mod.subtract(BigInteger.TWO), mod)` vs `BigInteger.TWO.modPow(mod.subtract(BigInteger.TWO), mod)`:
>>> 
>>> ```
>>> Benchmark        (messageLength)   Mode  Cnt         Score         Error  Units
>>> Signatures.pow1               64  thrpt   15  67352286,115 ± 1281517,907  ops/s
>>> Signatures.pow2               64  thrpt   15     62431,716 ±    1056,398  ops/s
>>> ```
>>> 
>>> for IntegerModuloP the result should not depend on base, and if it does, we should fix that.
>> 
>> Well, if you ever encounter the special cased "ONE" during ECDSA signature, you have a bigger problem than that the exponentiation is not exactly constant time. Also, if you can get close enough to the system doing the signing to be able to measure the time of the exponentiation precisely enough to differentiate one really occurring base from another -- you only have one chance to measure, so cannot average out noise -- than again, you probably have better methods to get to the key than trying to measure time.
>
>> ... you only have one chance to measure, so cannot average out noise ...
> 
> There are cases that one chance is enough to place an attack.  We normally don't discuss vulnerability details in public, please send me an email in private if more details is required.
> 
>>  ... than again, you probably have better methods to get to the key than trying to measure time.
> 
> I may have to agree that better methods may exist.  But better methods do not imply that we can let this method go.

> Hi @XueleiFan, can you wait for approval from @ferakocz? Thanks.

I will see if I can get it by the end of this Tuesday.

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

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