Re: [Cfrg] Hardware requirements for elliptic curves

Alyssa Rowan <akr@akr.io> Tue, 02 September 2014 13:05 UTC

Return-Path: <akr@akr.io>
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 060421A0363 for <cfrg@ietfa.amsl.com>; Tue, 2 Sep 2014 06:05:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Level:
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, 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 HYNCZCoFkmfG for <cfrg@ietfa.amsl.com>; Tue, 2 Sep 2014 06:05:43 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB4F1A0369 for <cfrg@irtf.org>; Tue, 2 Sep 2014 06:05:42 -0700 (PDT)
User-Agent: K-9 Mail for Android
In-Reply-To: <85d1c59362684615b0beeea1c2a48dd8@AMSPR04MB518.eurprd04.prod.outlook.com>
References: <85d1c59362684615b0beeea1c2a48dd8@AMSPR04MB518.eurprd04.prod.outlook.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
From: Alyssa Rowan <akr@akr.io>
Date: Tue, 02 Sep 2014 14:05:43 +0100
To: cfrg@irtf.org
Message-ID: <828996e7-465b-4c92-b91c-b5604365f986@email.android.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/NglUomgv-H_pcrAKkUK-w7BuqU0
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: Tue, 02 Sep 2014 13:05:46 -0000

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