Re: [Cfrg] Hardware requirements for elliptic curves

Paul Lambert <paul@marvell.com> Mon, 08 September 2014 05:26 UTC

Return-Path: <paul@marvell.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 C3A631A6F05 for <cfrg@ietfa.amsl.com>; Sun, 7 Sep 2014 22:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.433
X-Spam-Level:
X-Spam-Status: No, score=0.433 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 8Xvwh_RfvIdF for <cfrg@ietfa.amsl.com>; Sun, 7 Sep 2014 22:26:03 -0700 (PDT)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B9F1A6F04 for <cfrg@irtf.org>; Sun, 7 Sep 2014 22:26:03 -0700 (PDT)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s885PjcP014997; Sun, 7 Sep 2014 22:26:00 -0700
Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0b-0016f401.pphosted.com with ESMTP id 1p7g6ap0ky-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 07 Sep 2014 22:26:00 -0700
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([fe80::5efe:10.93.76.24%18]) with mapi; Sun, 7 Sep 2014 22:25:59 -0700
From: Paul Lambert <paul@marvell.com>
To: Michael Hamburg <mike@shiftleft.org>, Alyssa Rowan <akr@akr.io>
Date: Sun, 07 Sep 2014 22:25:57 -0700
Thread-Topic: [Cfrg] Hardware requirements for elliptic curves
Thread-Index: Ac/LJV8gLcN1Yje0S+uqEf+GnXJmAQ==
Message-ID: <D0328B2A.4C17D%paul@marvell.com>
References: <85d1c59362684615b0beeea1c2a48dd8@AMSPR04MB518.eurprd04.prod.outlook.com> <828996e7-465b-4c92-b91c-b5604365f986@email.android.com> <12A4E7B4-8303-449F-A04B-8366BBC5B1E3@shiftleft.org>
In-Reply-To: <12A4E7B4-8303-449F-A04B-8366BBC5B1E3@shiftleft.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.4.140807
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-09-08_01:2014-09-05,2014-09-07,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409080064
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/fsV0iH1zYN4tJfw_NxY1B0DaRYg
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Hardware requirements for elliptic 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: Mon, 08 Sep 2014 05:26:06 -0000


On 9/2/14, 9:31 AM, "Michael Hamburg" <mike@shiftleft.org> wrote:

>I agree with Alyssa that hardware performance isn¹t our concern here.
>
>However, I¹m curious about Joppe Bos¹ assertion that random primes are
>just as fast and more secure in hardware.  What kind of hardware are you
>thinking about?  Some kind of residue number system?  Or a bit-at-a-time
>reduction system?

I work at a chip company Š checking on design considerations:
 - random primes and special run at the same speed
 - flexibility and die size are more important than prime specific
optimization

Hardware performance should not be used as a reason to eliminate random
primes.

Paul


>
>I have some limited experience in crypto hardware design, in particular
>working with a hardware modulo multiplier.  If I recall correctly, adding
>support for a handful of the NIST primes (192, 224, 256 and 384 maybe?)
>cost about 10% area overhead in our lightweight design, for double the
>performance.
>
>That said, this hardware used a Montgomery reduction, so the same support
>would have required more work for a 2^big-small prime.  But I¹m sure it
>can still be done.
>
>‹ Mike
>
>> On Sep 2, 2014, at 6:05 AM, Alyssa Rowan <akr@akr.io> wrote:
>> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>> 
>> On 2 September 2014 12:43:19 BST, Joppe Bos <joppe.bos@nxp.com> wrote:
>>> The current discussion around the requirements, and the performance
>>> aspects,
>>> have mainly been approached from a software implementation point of
>>> view. As
>>> one of the authors of the NUMS curves, I have been responsible for this
>>> as
>>> well. With this message I would like to provide a hardware perspective:
>>> more
>>> specifically, I would like to put forward some requirements which are
>>> concerned with hardware specific attacks.
>> 
>> Thank you; an interesting perspective, if I may say so.
>> 
>> Of course, there's more than one way to do it. Vendors seem to use a
>>variety of techniques for side-channel countermeasures, and other
>>techniques prefer different environments.
>> 
>> For example, balanced dual-rail logic and smaller constant-time/power
>>implementations (along with an awful lot of dead junk gates, for reasons
>>I can't quite fathom but that may be a poor attempt at DFA
>>countermeasures?).
>> 
>> Or several other implementations from multiple vendors that are
>>actually based on either specialised microcontrollers or commodity CPUs
>>with specialised firmware, resulting in what may be more accurately
>>characterised as a constrained/specialised software implementation: I
>>think this may be the overall general approach that is the most
>>flexible, modular and reusable, which may be why it's the most favoured
>>approach by most other smart card & HSM vendors, from what I've seen?
>> 
>> Random primes have unfortunate software performance, including
>>constrained performance.
>> 
>> We are not concerned with EMV "security" here in CFRG at all, but with
>>making suggestions for *internet* protocols.
>> 
>> I think it would be a mistake to allow old hardware implementations to
>>(yet again) needlessly overshadow improved software ones: the majority
>>of implementations on the internet will invariably be software. I feel
>>we are being asked for new recommendations here, not old ones, but of
>>course, that's only my perspective.
>> 
>> - --
>> /akr
>> -----BEGIN PGP SIGNATURE-----
>> Version: APG v1.1.1
>> 
>> iQI3BAEBCgAhBQJUBcCnGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
>> jtkWi2t6o9sQAJpzXq7NOEzN8GMtwLI5tleXrlrNKDaJnAjVnV3Um8jMjXQR7EKS
>> pVUKMykomMhRvTAqfAQGWPBNIij9kRV5nT+3k+LYy6R1uuhS7Bdk3qV7DEEhmi06
>> shBK0uW2nic7PiXfwNpBBfrDPdLC2V035dLYD/uRtGPxWg69O4har82sjsIa7Bpm
>> ACnZwGxkgn1Mqem6IitSu6zs3XbnBTRVHvD3ttoi7gG5vD9MrQOCsHcWsqvkYIuD
>> 6E8N1ioL+5Yv4KhpVmv7NseP4Vl/anXYm5PEXyqVkcZlXtoaDXfJMbZAlolSCiPq
>> oaS4yGsGJV+g1HRMUr080jtlNuJKz3QiQqka91stvz83/fMIYhB3Y9Gy7z/0ojMF
>> GbKgkt9u31G4srPioFkDZjYPng7RQpwQz0Js3hWje3IVGiG0igEx1MlDrlCuIvlf
>> t2DBoxm61FCv+uRbZjXcZI7t/2orAB+5U75jx7yy9rO4WDcZx+QPEa1r3utQ1gBm
>> p48lc2NlDsxF7lQUPvpsmtnboYa7yISMefV+rLHX1hf+mgDMd1f9Wm/Dv3t8p53l
>> L0rFx0hPv9Lk4Kx/U21QZBa3rNldGyR9V+asBQz65G2C027rWv2K1mrzFMQwphfq
>> xJubu9iKqT/JTzk0brRQCd9tY3ljLSW8Y0v9y4enCb5Z015tFno2oIlm
>> =Fk5G
>> -----END PGP SIGNATURE-----
>> 
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg
>
>_______________________________________________
>Cfrg mailing list
>Cfrg@irtf.org
>http://www.irtf.org/mailman/listinfo/cfrg