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

>

>

>

>