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

Florent Daigniere <[email protected]> Tue, 29 Nov 2016 21:01:50 +0100
Newsgroups	gmane.network.freenet.devel
Message-ID	<[email protected]>
We use cached-ephemeral DH... but not always BC's implementation...

"it's complicated"

Not worth loosing sleep over it IMHO; we will just ensure that next
build will ship with the yet-to-be-released fixed version of BC.

Florent

On Tue, 2016-11-29 at 19:19 +0000, Matthew Toseland wrote:
> 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], announce-crypto@bouncycastle.
> org
> 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

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