Re: [Cfrg] Hardware requirements for elliptic curves

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 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