Re: [Cfrg] Criteria for the selection of new ECC mechanisms

Johannes Merkle <johannes.merkle@secunet.com> Wed, 30 April 2014 14:14 UTC

Return-Path: <Johannes.Merkle@secunet.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89681A6FC2 for <cfrg@ietfa.amsl.com>; Wed, 30 Apr 2014 07:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Level:
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qv2vDpMi31bC for <cfrg@ietfa.amsl.com>; Wed, 30 Apr 2014 07:14:11 -0700 (PDT)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 847071A078F for <cfrg@irtf.org>; Wed, 30 Apr 2014 07:14:11 -0700 (PDT)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 71F791A00A6; Wed, 30 Apr 2014 16:14:08 +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 xKL31Orb73nZ; Wed, 30 Apr 2014 16:14:03 +0200 (CEST)
Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id D2D9A1A00A3; Wed, 30 Apr 2014 16:14:03 +0200 (CEST)
Received: from [10.53.40.204] (port=62954 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1WfVGt-00069L-8m; Wed, 30 Apr 2014 16:14:03 +0200
Received: from [10.208.1.57] (10.208.1.57) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 30 Apr 2014 16:14:03 +0200
Message-ID: <5361052A.9030205@secunet.com>
Date: Wed, 30 Apr 2014 16:14:02 +0200
From: Johannes Merkle <johannes.merkle@secunet.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Rene Struik <rstruik.ext@gmail.com>, David McGrew <mcgrew@cisco.com>
References: <535FB927.8080909@cisco.com> <535FDD0A.7070206@gmail.com> <535FEDA2.4090502@cisco.com> <535FF2BB.3050703@gmail.com>
In-Reply-To: <535FF2BB.3050703@gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.208.1.57]
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/ACNZn2qQh5bKauC3c3g2zmLHejQ
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Criteria for the selection of new ECC mechanisms
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Apr 2014 14:14:14 -0000

Rene Struik wrote on 29.04.2014 20:43:
> On 4/29/2014 2:21 PM, David McGrew wrote:
>>
>> Just for clarity: you are not disagreeing with R8, just saying that it doesn't go far enough in expressing the
>> requirements of avoiding side channels, right?
> RS>>
> In theory, I can imagine that one could have non-constant time implementations that nevertheless do not leak any
> meaningful info, although, admittedly, I do not recall having seen public papers in that direction. Stipulating point
> solution requirements re implementation security (constant-time, avoids twisted curve attacks, invalid points, etc.)
> does not capture the real requirement that we simply want good real-world implementation security. (This is a huge area
> with many pitfalls and something most CFRG people probably do not closely follow that much (CHES, FDTC, COSADE, CARDES,
> etc.), but nevertheless, in my mind, present a much higher threat than any algorithmic consideration (besides the
> obvious), esp. with highly constrained devices deployed in critical infrastructure (internet of things type, sensors,
> etc.).)
> <<RS
>>>>
>>>>    R9.  Required: resist twist attacks [2]
>>> RS>>
>>> This is just and example of a particular implementation attack in a very wide spectrum. It would be a shame if this
>>> were supposed to rule out any non "twist-secure" curves, just because of this stipulation. There are many ways to
>>> skin a cat or here and providing secure implementations.
>>> <<RS
>>
>> So, would you be comfortable moving R9 to "desired"?   Are there other attacks that we should enumerate?
> RS>>
> This is still an area in lots of flux. Well, a good read would be
> Side Channel Resistance - State-of-Art of Secure ECC Implementations, Attacks and Countermeasures (Junfeng Fan, Guo, De
> Mulder, Schaumont, Preneel, Verbauwhede, HOST 2010)
> <<RS

Another good starting point could be the following recommendations (targeted at CC certifications but applicable to
other implementations as well), which have been co-authored by Tanja Lange
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_46_ECCGuide_e_pdf.pdf

Johannes