Re: [Cfrg] Hardware requirements for elliptic curves

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