Re: [TLS] Safe ECC usage

Johannes Merkle <johannes.merkle@secunet.com> Fri, 04 October 2013 12:29 UTC

Return-Path: <Johannes.Merkle@secunet.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 C87C321F9BC1 for <tls@ietfa.amsl.com>; Fri, 4 Oct 2013 05:29:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 Uav8Kro4jtbr for <tls@ietfa.amsl.com>; Fri, 4 Oct 2013 05:29:35 -0700 (PDT)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 40EF421F8C65 for <tls@ietf.org>; Fri, 4 Oct 2013 05:18:39 -0700 (PDT)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id D39291A0084; Fri, 4 Oct 2013 14:18:37 +0200 (CEST)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id E5KPun0O_qg2; Fri, 4 Oct 2013 14:18:36 +0200 (CEST)
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id BA7C31A0083; Fri, 4 Oct 2013 14:18:36 +0200 (CEST)
Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Oct 2013 14:18:37 +0200
Message-ID: <524EB21C.6050606@secunet.com>
Date: Fri, 04 Oct 2013 14:18:36 +0200
From: Johannes Merkle <johannes.merkle@secunet.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Dan Brown <dbrown@certicom.com>
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>
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Oct 2013 12:18:37.0096 (UTC) FILETIME=[DA3B3280:01CEC0FB]
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: Fri, 04 Oct 2013 12:29:46 -0000

> random prime instead of a special one incurs a computational cost.  So, I
> think I was reasonable to infer that Brainpool was implying that special
> fields were lacking in security.  (The implication against special values
> may then be inferred further.)  

The primes used by NIST curves are so special that there is less room for suspicion of a backdoor in the primes than in
the curve.

Our main concern with the special primes used by NIST curves is that their special form requires more caution to harden
your arithmetic against side-channel attacks. As a matter of fact, Sakai & Sakurai, for instance, have proposed power
analysis attacks targeting arithmetic on Pseudo-Mersenne primes. And we don't know, if the NSA has developed improved
side-channel attacks against ECC over such fields.

As I understand, the Curve25519 papers address side-channel immunity by specifying an eligible arithmetic. No objection
to that approach, but for the Brainpool curves we had a different one.

Another aspect was that we avoid many patents by not using Pseudo-Mersenne primes.



Johannes