Re: [TLS] Safe ECC usage

Dan Brown <dbrown@certicom.com> Thu, 17 October 2013 15:46 UTC

Return-Path: <dbrown@certicom.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26BB11E8269 for <tls@ietfa.amsl.com>; Thu, 17 Oct 2013 08:46:32 -0700 (PDT)
X-Quarantine-ID: <HS1dYyMdwl+V>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -2.224
X-Spam-Level:
X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_16=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HS1dYyMdwl+V for <tls@ietfa.amsl.com>; Thu, 17 Oct 2013 08:46:27 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id C5DD011E825D for <tls@ietf.org>; Thu, 17 Oct 2013 08:46:18 -0700 (PDT)
Content-Type: multipart/mixed; boundary="===============0531799655=="
MIME-Version: 1.0
Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 17 Oct 2013 11:46:14 -0400
Received: from XMB117CNC.rim.net ([fe80::24f3:cc30:b596:7ca0]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0123.003; Thu, 17 Oct 2013 11:46:13 -0400
From: Dan Brown <dbrown@certicom.com>
To: "'watsonbladd@gmail.com'" <watsonbladd@gmail.com>
Thread-Topic: [TLS] Safe ECC usage
Thread-Index: AQHOxuJRxn3XJXmgAkKRAg2ZE6kwf5n3qq2ggAC0kACAAKQ6QA==
Date: Thu, 17 Oct 2013 15:46:13 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5BEC2EC@XMB117CNC.rim.net>
References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> <20131003010455.17185.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDECA6@XMB116CNC.rim.net> <20131005192950.27059.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BE4A9D@XMB116CNC.rim.net> <20131012003058.669.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BEBAA5@XMB117CNC.rim.net> <CACsn0c=bSTMWwuHxD3eE3ABC_AxVRt-BOTybEr7umPQD5NB+cA@mail.gmail.com>
In-Reply-To: <CACsn0c=bSTMWwuHxD3eE3ABC_AxVRt-BOTybEr7umPQD5NB+cA@mail.gmail.com>
Accept-Language: en-CA, en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.249]
MIME-Version: 1.0
Cc: "'djb@cr.yp.to'" <djb@cr.yp.to>, "'tls@ietf.org'" <tls@ietf.org>
Subject: Re: [TLS] Safe ECC usage
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Oct 2013 15:46:33 -0000


Watson Ladd wrote
> Dan Brown wrote
>
> > Based on this score, if I had to guess what the next attack would be,
> > then I would guess special.  An attack on random would be a
> breakthrough.
> > Therefore, trying to choose a random curve is a best guess approach.
> >
> ...
> >
> > Uncertainty, "no idea", about unknown attacks is a given, but we
> > should still try to resist them, even if that means making
> assumptions
> > and guessing.  Provably secure algorithm try to do this.  Previously
> unknown
> > attacks are known pop up, occasionally.   But, we also give weight to
> the
> > effort that people have exerted in trying to find attacks, to infer
> > the unlikelihood of new attacks being discovered.
> >
> So you agree that E(random curve falls to unknown attack)=E(Curve25519
> falls to random attacks). (This is is obvious unless cosmic conspiracy
> happens, and if it isn't, think about it). But now the question is

Sure, but confining ourselves to "random attacks' is way too optimistic. 
Future, and unknown, attacks will not necessarily be random.

Also, that is not at all what I was talking about in the text you quoted.  In 
fact, earlier in this thread, I mentioned this random attack argument as being 
almost circular, assuming one what one aims to establish, and that this was 
similar to what Koblitz, Koblitz and Menezes argued.

Well, maybe you mean something other than "random attacks"?


> whether the author of the random curve really picked it at random, vs
> specified a curve. And then the fact that DJB specified at most 17 bits
> or so is very important: a new attack would have to work on 2^{-17} of
> all curves to work on Curve25519.

Just curious: where's the 17 from?

Why couldn't a new attack just work on one curve, namely Curve25519?  If I 
understand correctly, DJB has argued that the ECC theory and experience would 
be evidence for a claim similar, but perhaps not as strong, as your claim.

Sure, a new attack could work against just one brainpool curve too.  But for 
brainpool, there a three prongs against such a single curve attack: the ECC 
theory and experience, the use of SHA1 of in brainpool definitions, the use of 
Pi and e in the brainpool curves.  That would definitely be a "cosmic 
conspiracy".

The MOV and SASS worked on small fractions of curves.  If I recall correctly, 
in both cases there had already been proposals to use special curves (for 
efficiency and other convenience reasons) affected by these attacks, before 
the attacks were discovered.  The risk of this happening again for Curve25519 
is much smaller, because of the many intervening years of research into ECC. 
That's why I view Curve25519 as safe, but in the context of resisting unknown 
attacks, the evidence supports brainpool, or an honestly-generated P-256 as 
slightly safer.

...

The most compelling argument, at least to me, against my position is the 
Pohlig--Hellman attack, which DJB already raised a couple times.  I've exclude 
this attack from my evidence, because it is generic to DH/DL, and Curve25519, 
Brainpool and P256 all address PH attacks in the same way, with a low-pass 
filter.

Arguably, we could have boosted the group size, and resisted PH with a 
high-pass filter, resulting in DH/DL that belong to a larger class of groups. 
That would have been less efficient, but also not very compelling for security 
because is there is evidence of low-density generic DH/DL attacks, i.e. 
special groups, that need to be avoided.  Thus the decision to resist PH by 
using a low-pass filter (e.g. searching random orders until one nearly prime 
was found) does not seem to introduce a risk.  In the case of PH-protected 
ECC, the weak argument to avoid special curves is to avoid another MOV or 
SASS.




---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.