Strange result with modular math functions

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Strange result with modular math functions

Friel, Joseph
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




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

BC Security Advisory (was: Strange result with modular math functions)

Peter Dettman-3
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
>
>
>
>


Loading...