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