On Mon, 31 Oct 2022 17:19:21 GMT, Xue-Lei Andrew Fan <xue...@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
