Fwd: [announce-crypto] BC Security Advisory (was: Strange result with modular math functions)

Matthew Toseland <[email protected]> Tue, 29 Nov 2016 19:19:18 +0000
Newsgroups	gmane.network.freenet.devel
Message-ID	<[email protected]>
I think this doesn't affect us as we use ephemeral DH and then sign it
with ECDSA? Florent?



-------- Forwarded Message --------
Subject: 	[announce-crypto] BC Security Advisory (was: Strange result
with modular math functions)
Date: 	Tue, 29 Nov 2016 13:55:55 +1100
From: 	Peter Dettman <[email protected]>
Reply-To: 	[email protected]
To: 	BouncyCastle <[email protected]>,
'[email protected]'
<[email protected]>,
[email protected], [email protected]
CC: 	[email protected]



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
> 
> 
> 
>

_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
signature.asc (application/pgp-signature, 819 B)