Hi Joe, Yes, the BC result is in error. We are aware of the issue, but were holding off announcing it until fixed in our next release. Since it is now public anyway, I will give a few details, and we will commit the fixes shortly.
The problem is actually a carry propagation bug in the Nat192.square method. The same basic issue also affects Nat128, Nat160, Nat256, and so other curves are likewise affected, not just secp384r1. It affects both our Java and C# APIs. These methods are presently only used (internally) by the custom elliptic curve implementations. The bug(s) can lead to an erroneous scalar multiplication (SM), by our estimate the probability is less than 2^-48 per SM for randomly selected input. All scalar multipliers perform a point validation before returning their result, so if the bug actually occurs in normal usage, the SM should fail. We consider the probability of an undetected fault in a single SM to be (very conservatively) less than 2^-100. It is however possible to choose an input that will fault or not depending on some leading bits of the scalar, which can incrementally reveal a long-term key. ECDH with static keys (i.e. re-using the same key for many ECDH computations, as e.g. with the non-ephemeral ECDH ciphersuites in TLS) is therefore expected to be exploitable as described in https://eprint.iacr.org/2011/633, although with a substantially higher attack cost. Note that ECDH ciphersuites are not enabled by default in our TLS/JSSE implementations, nor recommended in general, but they can be enabled explicitly by users. We recommend that users DO NOT enable static ECDH ciphersuites in TLS/JSSE. New releases with fixes for both Java and C# are expected next week. Regards, Pete Dettman On 29/11/2016 5:17 AM, Friel, Joseph wrote: > Hi, > > I've been using Bouncy Castle to do some elliptic curve/modular math > computations, and I've come across some strange results. > Specifically, the SecP384R1Field.square() function does not appear to > always return a correct result. Here is a short test case where the > BouncyCastle modular square differs from Java's BigInteger modular > square: > > https://gist.github.com/anonymous/e6322f0a7bf5a76a888dd1708f2510ca > > The BigInteger result was cross-checked against an independent > implementation (Python), so I believe it is correct and the > BouncyCastle result is in error. Can anyone point out anything I > might be doing wrong that would explain this discrepancy? > > > > Thanks, > > Joe Friel > > > >
