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-----
- [Cfrg] Hardware requirements for elliptic curves Joppe Bos
- Re: [Cfrg] Hardware requirements for elliptic cur… Alyssa Rowan
- Re: [Cfrg] Hardware requirements for elliptic cur… Michael Hamburg
- Re: [Cfrg] Hardware requirements for elliptic cur… Johannes Merkle
- Re: [Cfrg] Hardware requirements for elliptic cur… Michael Hamburg
- Re: [Cfrg] Hardware requirements for elliptic cur… Alyssa Rowan
- Re: [Cfrg] Hardware requirements for elliptic cur… Andy Lutomirski
- Re: [Cfrg] Hardware requirements for elliptic cur… Robert Ransom
- Re: [Cfrg] Hardware requirements for elliptic cur… Lochter, Manfred
- Re: [Cfrg] Hardware requirements for elliptic cur… Johannes Merkle
- Re: [Cfrg] Hardware requirements for elliptic cur… Wieland.Fischer
- Re: [Cfrg] Hardware requirements for elliptic cur… Alyssa Rowan
- Re: [Cfrg] Hardware requirements for elliptic cur… Watson Ladd
- Re: [Cfrg] Hardware requirements for elliptic cur… Patrick Georgi
- Re: [Cfrg] Hardware requirements for elliptic cur… Paul Lambert
- Re: [Cfrg] Hardware requirements for elliptic cur… Torsten Schuetze
- Re: [Cfrg] Hardware requirements for elliptic cur… Torsten Schuetze
- Re: [Cfrg] Hardware requirements for elliptic cur… Andy Lutomirski
- Re: [Cfrg] Hardware requirements for elliptic cur… Mike Hamburg
- Re: [Cfrg] Hardware requirements for elliptic cur… Torsten Schuetze
- Re: [Cfrg] Hardware requirements for elliptic cur… Watson Ladd
- Re: [Cfrg] Hardware requirements for elliptic cur… Mike Hamburg
- Re: [Cfrg] Hardware requirements for elliptic cur… Alyssa Rowan
- Re: [Cfrg] Hardware requirements for elliptic cur… Lochter, Manfred
- Re: [Cfrg] Hardware requirements for elliptic cur… Alyssa Rowan
- Re: [Cfrg] Hardware requirements for elliptic cur… Dirk Feldhusen
- Re: [Cfrg] Hardware requirements for elliptic cur… Lochter, Manfred
- Re: [Cfrg] Hardware requirements for elliptic cur… Ilari Liusvaara
- Re: [Cfrg] Hardware requirements for elliptic cur… Watson Ladd
- Re: [Cfrg] Hardware requirements for elliptic cur… Peter Gutmann
- [Cfrg] Trusting government certifications of cryp… D. J. Bernstein
- Re: [Cfrg] Trusting government certifications of … David Jacobson
- Re: [Cfrg] Trusting government certifications of … Torsten Schütze
- Re: [Cfrg] Trusting government certifications of … Watson Ladd
- Re: [Cfrg] Trusting government certifications of … Dirk Feldhusen
- Re: [Cfrg] Trusting government certifications of … Michael Hamburg
- Re: [Cfrg] Trusting government certifications of … Dirk Feldhusen
- Re: [Cfrg] Trusting government certifications of … Lochter, Manfred
- Re: [Cfrg] Trusting government certifications of … Mike Hamburg
- Re: [Cfrg] Primes vs. hardware side channels David Leon Gil
- [Cfrg] Primes vs. hardware side channels D. J. Bernstein
- Re: [Cfrg] Primes vs. hardware side channels Alyssa Rowan