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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
