On Wed, 2 Nov 2022 14:44:30 GMT, Ferenc Rakoczi <d...@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
