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

[Xue-Lei Andrew Fan]

On Wed, 2 Nov 2022 14:44:30 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> > > ... 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.
> 
> Well, I doubt this would be one of those cases you have in mind... Your method of computing the inverse looks good to me, but I still think that if we can achieve a better result with an existing general method then we should do that instead of writing special ones for every curve. I think there is a risk in having more code, too.

There was vulnerability reported to other TLS vendors for non-constant inversion computation and we was OK.  The new implementation performance in this PR is pretty close to using BigIntegers.   We might not want to take the risks by introducing the branchless implementation back.  

I agree that more code means more risks.  I hope the risk is under control and get examined.  It also come with an advantage.  With this update, if secp256r1 broken, secp521r1 may be still safe as they are using different code base.

Thank you for looking into the implementation.

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

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