Re: [Cfrg] Primes vs. hardware side channels
Alyssa Rowan <akr@akr.io> Fri, 17 October 2014 06:16 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 457811A90C5 for <cfrg@ietfa.amsl.com>; Thu, 16 Oct 2014 23:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sNaKh4cxy7cJ for <cfrg@ietfa.amsl.com>; Thu, 16 Oct 2014 23:16:38 -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 BCEDB1A8F46 for <cfrg@irtf.org>; Thu, 16 Oct 2014 23:16:38 -0700 (PDT)
Message-ID: <5440B447.5060509@akr.io>
Date: Fri, 17 Oct 2014 07:16:39 +0100
From: Alyssa Rowan <akr@akr.io>
MIME-Version: 1.0
To: "cfrg@irtf.org" <cfrg@irtf.org>
References: <20141017005511.14016.qmail@cr.yp.to>
In-Reply-To: <20141017005511.14016.qmail@cr.yp.to>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/1pERfDrWN_uCQ8b8T080SgkwWYE
Subject: Re: [Cfrg] Primes vs. hardware side channels
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: Fri, 17 Oct 2014 06:16:40 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 17/10/2014 01:55, D. J. Bernstein wrote: > This seems safe if the bits are further obscured by a considerable > level of physical noise. However, for plausibly smaller noise > levels this is breakable, as illustrated by the recent paper by > Schindler and Wiemers. In line with my previous comments, I'm just going to +1 all of this message, but particularly this bit right here. I also have a big question about whether wanting to minimise costs by reusing certifications for existing RSA hardware - and reusing that existing hardware for ECC - is necessarily sound in light of new research, new information, serious concerns raised about the efficacy and integrity of existing certification processes, wanting open alternatives, not working well with the NIST curves either, and so on. And there again is the point I made earlier: if they want Brainpool, they've already _got_ Brainpool. Nobody else seems to want it. That's why we're being asked for _new_ curves. And why they should design _new_ hardware to support them. (And protect against 'new' threats.) - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUQLRHAAoJEOyEjtkWi2t6hS4P/1aSXUZOFwqJcZgl1KUGwbGa NNivBhVSKWWs1dVRa+AbwUbEtN3rbkIG3NGhKikItlrLwSGLD1PSaEbjDYHZFGAC u57iwJo5owgxNJBmrOhCZb43Tgf4QJeGr5UddbLqQLZ1/RX6dw9Aw2qJUF3BrkZ5 sqEkdu3hrTcaqh5ieSXulAZPau7WnK1BZ44Y01cv4tk/nE+zpMUQsIziyiFtSLzd pbaBjBpC3AT3Y58uFeGqyRSadYkXZdkauBuVTwPRGTijPhSD5Jg6+UJ3i+WaYxKK FymR2dBp2oLQDe2P9wd1MK16qY+B8g7nIWAXcmfv/h61bQjKSwU4tVrnV4g4ZIj4 S16i4QGajAmzTDZbwB3sfPvhiD/zcBDALhsD6yLiVQWAtvcGE+a6OYx0rqqVwDcr EAEofn7gqWnvhHABopOhxdJe6voVyEzq0LrXhKjDbGYOiTb+TiSxdfXikxgrU0IU 2eqa/n83WRuQuK1SG2v0w77kgNowTpPC5GsOLLJRm1C4IKzTcW11JyQwPhVEPX4d QqSVijf9wEJOkqK4LZLmZXTcTPpv2IqMRy98q5tXm5D69qcTGBPwKjHIWDNeGMRe rFsvuDe7t+97GcF0K8EGH31EdUWibzh7UiXl7SV8T0xd4Zf39T7ZRRuRP+vHSW8h 9dS/nCuE70ASuGsXCGwa =OzoT -----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
- [Cfrg] Primes vs. hardware side channels D. J. Bernstein
- Re: [Cfrg] Primes vs. hardware side channels David Leon Gil
- Re: [Cfrg] Primes vs. hardware side channels Alyssa Rowan