Re: [Cfrg] revised requirements for new curves
Torsten Schuetze <torsten.schuetze@gmx.net> Thu, 11 September 2014 11:41 UTC
Return-Path: <torsten.schuetze@gmx.net>
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 D63011A896A for <cfrg@ietfa.amsl.com>; Thu, 11 Sep 2014 04:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.552
X-Spam-Level:
X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] 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 3aWSzYy_QWJY for <cfrg@ietfa.amsl.com>; Thu, 11 Sep 2014 04:41:25 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E10F1A6F1F for <cfrg@irtf.org>; Thu, 11 Sep 2014 04:41:10 -0700 (PDT)
Received: from [192.168.0.12] ([109.192.91.63]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MbfnB-1XkXbN2ud3-00J57M; Thu, 11 Sep 2014 13:41:08 +0200
Message-ID: <54118A65.8070608@gmx.net>
Date: Thu, 11 Sep 2014 13:41:25 +0200
From: Torsten Schuetze <torsten.schuetze@gmx.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: cfrg@irtf.org, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
In-Reply-To: <D0333B6F.2C8CF%kenny.paterson@rhul.ac.uk>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:YdqQkbOayVkf/HoqzZ5au9kXIujame815AH5nM3oJn1SNb9tEx5 osJ2y6eBCvoIjyZZGTVeHMJ/taA6JZ0k9nz0GcdF6g5X20d6uaZRXmqf10epQya1edlEvKT VJ3ONzJ9usME2IGpJxCFr/7H339MsYzEBqVmRVEP/yUxmnm+FXQbFDVSX3cmg8hlUtweYoU dRTG91NPIZj2dk+9ib3rA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/TY-2Al-G9ACoDP2Sqfq7SD023Uo
Subject: Re: [Cfrg] revised requirements for new curves
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: Thu, 11 Sep 2014 11:41:27 -0000
On Sep 08, 2014 10:23:14 +0000 "Paterson, Kenny" <Kenny.Paterson at rhul.ac.uk> wrote: > Performance > > PE1. Required: amenable to both compact and fast implementations of curve > operations in software, across a wide range of processor types. [C] > > PE2. Desired: amenable to both compact and fast implementations of curve > operations in hardware. [RC] Dear Kenny, is this to be understood in the more general sense: PE1. software in a secure environment, e.g., on a secured server, i.e., where only the global timing as side-channel is relevant PE2. software on constrained devices or hardware in a hostile environment, i.e., where the full set of local and global side-channels applies. ? Or in the strict sense? My point is, that most of the discussion for PE1 was on software with a constant global timing, not on more specific local attacks, as CPA or EMA. For example, an ECC software implementation on a constrained device/embedded device in a hostile environment or under an adversary with high attack potential would fall into PE1 according to the original classification and into PE2 according to the refined classification. Surely, for such an implementation much more than timing constant arithmetic would be necessary, e.g., all kinds of blinding and fault attack countermeasures. Regarding non-symmetry in refined PE1/2: I don't know of any sensible hardware which is designed to be run only in a secured environment. In those cases, often software would perform better. One further question: At least in the "hardware thread" the issue of flexibility came up. I could not find this completely covered by your requirements. But perhaps this is the greatest disagreement in the discussion (random primes vs. fixed, specific primes). Of course, a selected curve has to be very specific, but I mean if the curve encourages you to an high-performant, but inflexible arithmetic. Cheers, Torsten -- ROHDE & SCHWARZ SIT GmbH Hemminger Str. 41 http://www.sit.rohde-schwarz.com mailto:torsten.schuetze@rohde-schwarz.com
- Re: [Cfrg] revised requirements for new curves Paterson, Kenny
- Re: [Cfrg] revised requirements for new curves William Whyte
- Re: [Cfrg] revised requirements for new curves Manuel Pégourié-Gonnard
- Re: [Cfrg] revised requirements for new curves Phillip Hallam-Baker
- Re: [Cfrg] revised requirements for new curves Stephen Farrell
- Re: [Cfrg] revised requirements for new curves Paterson, Kenny
- Re: [Cfrg] revised requirements for new curves Paterson, Kenny
- Re: [Cfrg] revised requirements for new curves Watson Ladd
- Re: [Cfrg] revised requirements for new curves Paterson, Kenny
- Re: [Cfrg] revised requirements for new curves David Jacobson
- Re: [Cfrg] revised requirements for new curves Manuel Pégourié-Gonnard
- Re: [Cfrg] revised requirements for new curves D. J. Bernstein
- Re: [Cfrg] revised requirements for new curves Michael Hamburg
- Re: [Cfrg] revised requirements for new curves Paterson, Kenny
- Re: [Cfrg] revised requirements for new curves Adam Langley
- Re: [Cfrg] revised requirements for new curves Paterson, Kenny
- Re: [Cfrg] revised requirements for new curves Adam Langley
- Re: [Cfrg] revised requirements for new curves Damien Miller
- Re: [Cfrg] revised requirements for new curves Damien Miller
- Re: [Cfrg] revised requirements for new curves Torsten Schuetze
- Re: [Cfrg] revised requirements for new curves Eric Rescorla
- Re: [Cfrg] revised requirements for new curves Markulf Kohlweiss
- Re: [Cfrg] revised requirements for new curves Phillip Hallam-Baker
- Re: [Cfrg] revised requirements for new curves Alyssa Rowan
- Re: [Cfrg] revised requirements for new curves Michael Hamburg
- Re: [Cfrg] revised requirements for new curves Phillip Hallam-Baker
- Re: [Cfrg] revised requirements for new curves Michael Hamburg
- Re: [Cfrg] revised requirements for new curves Andrey Jivsov
- Re: [Cfrg] revised requirements for new curves Andrey Jivsov