Re: [Cfrg] Hardware requirements for elliptic curves

Alyssa Rowan <akr@akr.io> Sat, 06 September 2014 14:52 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 A5C711A0426 for <cfrg@ietfa.amsl.com>; Sat, 6 Sep 2014 07:52:50 -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 NuN6tEZI7Obu for <cfrg@ietfa.amsl.com>; Sat, 6 Sep 2014 07:52:49 -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 E94C71A040F for <cfrg@irtf.org>; Sat, 6 Sep 2014 07:52:48 -0700 (PDT)
Message-ID: <540B1FC6.7070206@akr.io>
Date: Sat, 06 Sep 2014 15:52:54 +0100
From: Alyssa Rowan <akr@akr.io>
MIME-Version: 1.0
To: cfrg@irtf.org
References: <85d1c59362684615b0beeea1c2a48dd8@AMSPR04MB518.eurprd04.prod.outlook.com> <828996e7-465b-4c92-b91c-b5604365f986@email.android.com> <12A4E7B4-8303-449F-A04B-8366BBC5B1E3@shiftleft.org> <54086138.6070205@secunet.com> <BDA5BE29-5F19-44B2-8C3D-8D5E1784B022@shiftleft.org> <54099FCC.6050200@secunet.com>
In-Reply-To: <54099FCC.6050200@secunet.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/LxVvPi2E4VhefHlF3Iop55iaR8M
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: Sat, 06 Sep 2014 14:52:50 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/09/2014 12:34, Johannes Merkle wrote:

> What I understood is that [hardware vendors] do not want to 
> specialize their hardware to minimize their investment while being
>  fully flexible (algorithm agile). […] Furthermore, I guess that
> new implementations can be built easier based on existing ones.

Quite. For decades, many vendors of cryptoprocessors have been basing
their implementations almost directly on existing ones with very few,
extremely conservative changes, presumably minimising their investment
by reusing as much as possible.

Respectfully, I do not think that conservative approach delivers
sufficient assurance where the integrity of the base is properly in
question: you don't add a conservatory to fix uncertain foundations.

While some existing hardware could indeed be adapted, whether abusing
the RSA multiplier where possible or (more likely, I feel) implementing
it entirely in firmware, I suggest those seeking these recommendations
for new elliptic curves, via an open process like this, should also have
plenty of concerns about crypto implementations presented as a closed
"black box" with an uncertain pedigree which has not also been designed,
audited, and certified as openly as possible from its inception. Rusty,
closed crypto hardware with new paintwork is, I feel, unlikely to meet
those needs.

I'm not aware of any cryptoprocessor vendor who has shipped any new
hardware like that, but I would heartily welcome and encourage it.

I gather a few efforts are under way from private teams, as has been
previously discussed.

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUCx/FAAoJEOyEjtkWi2t6234QAJOW1wa2qZTWgZKSzvU9tEqI
1FZ4t8r7YiRWQ/ptHnYDmqzIFlAJ3D5miXnFfaxK9+4dFLTbaUXvjDSIOM0LQzTo
rimr/iWmf+uGxmKO/Pn2kSNiDqh9oMiNvuo5n7Cl8ajdSYIYZT6hekRdjxkj5ZeS
3W/iiKzr5eMTwEBBnPgx7xdes9gd+DYAoX57HLluJ1rltrm0bQGu79Rorw/YlwB3
zbRduRhHrL6xwZJ53INQgDeLqSzw08GbE/4XTUtVe+DGL+cKXyS7tvm8E0J0s5KK
O3ebyRfu1/2FWa7O7R+idnCqW0RMaPaXyUVn/ZlyrCfFN/gocsRo7glVF3a38KIw
BzP3df6fNT5fnQBpb+qKdV0gmEck51nf/uuK6STSBf4+EpAFVg9wUt/MYsAEPDvz
qN0xrvFWt0TFXQNsVisgcMELuVuq5ErbdSuPm806nGlxNi1dvZ2J/jbaDuDIZlAA
GwArQ+HRS0i6BzSviz+WAu2aYUDt/XHYLCu6sopL/Gy4hQtVTB8eI9HvXuTTndHr
HSAC9w9CRM92G12tuNjBNxM2j7eSIbVDZaHBTr2FxzNr/0hbca/+N0gsXAU2nOPp
1ab8VlUcMptk8RT0A5+W9qSqa55HpTESjwLHtS/Emq6JPRd+LbEJIOXcdQYwb85T
0QQflmfQ3DN7IjeetivU
=QyHz
-----END PGP SIGNATURE-----