Re: [Cfrg] Hardware requirements for elliptic curves

Paul Lambert <> Mon, 08 September 2014 05:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C3A631A6F05 for <>; Sun, 7 Sep 2014 22:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.433
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8Xvwh_RfvIdF for <>; Sun, 7 Sep 2014 22:26:03 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2B9F1A6F04 for <>; Sun, 7 Sep 2014 22:26:03 -0700 (PDT)
Received: from pps.filterd ( []) by (8.14.5/8.14.5) with SMTP id s885PjcP014997; Sun, 7 Sep 2014 22:26:00 -0700
Received: from ([]) by 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 ([]) by ([fe80::5efe:]) with mapi; Sun, 7 Sep 2014 22:25:59 -0700
From: Paul Lambert <>
To: Michael Hamburg <>, Alyssa Rowan <>
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: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
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
Cc: "" <>
Subject: Re: [Cfrg] Hardware requirements for elliptic curves
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Sep 2014 05:26:06 -0000

On 9/2/14, 9:31 AM, "Michael Hamburg" <> 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

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


>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
>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 <> wrote:
>> Hash: SHA512
>> On 2 September 2014 12:43:19 BST, Joppe Bos <> 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
>> 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
>> 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 mailing list