Re: [Cfrg] big-endian short-Weierstrass please
Alyssa Rowan <akr@akr.io> Thu, 29 January 2015 07:13 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 713B21A8AFA for <cfrg@ietfa.amsl.com>; Wed, 28 Jan 2015 23:13:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.502
X-Spam-Level:
X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 BXpVTtGJZsA0 for <cfrg@ietfa.amsl.com>; Wed, 28 Jan 2015 23:13:18 -0800 (PST)
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 0F0F81A000C for <cfrg@irtf.org>; Wed, 28 Jan 2015 23:13:18 -0800 (PST)
Message-ID: <54C9DD8E.9040302@akr.io>
Date: Thu, 29 Jan 2015 07:13:18 +0000
From: Alyssa Rowan <akr@akr.io>
MIME-Version: 1.0
To: "cfrg@irtf.org" <cfrg@irtf.org>
References: <810C31990B57ED40B2062BA10D43FBF5D42BDA@XMB116CNC.rim.net> <87386ug2r7.fsf@alice.fifthhorseman.net> <810C31990B57ED40B2062BA10D43FBF5D4413B@XMB116CNC.rim.net> <87r3ueedx7.fsf@alice.fifthhorseman.net> <CAMm+Lwj6eG_KAhb-r5QrDeui7w8AoSN=71X8ywEyn9jj0rALQg@mail.gmail.com>
In-Reply-To: <CAMm+Lwj6eG_KAhb-r5QrDeui7w8AoSN=71X8ywEyn9jj0rALQg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/qBQRbWxfqCGPSrdpmFQFpua6d2U>
Subject: Re: [Cfrg] big-endian short-Weierstrass please
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: Thu, 29 Jan 2015 07:13:22 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 29/01/2015 00:37, Phillip Hallam-Baker wrote: > Right. The objective here is to dump all the existing code in the > trash and start again. Because we want the implementations to have > constant time implementations and to preclude the possibility of > malicious point attacks by choosing curves that allow us to easily > compute y from an x, and only sending the x. > > What we want to avoid at all costs is patent encumbrances. Dumping > Weierstrass is a pretty good start because that was the favorite > curve of the folk who applied for most of the patents. +1 to all of this. > The only area where I did have concerns is that to be able to > deploy crypto on these platforms I have to be able to buy FIPS > certified hardware or equivalent. It's probably going to have to be "equivalent", unless NIST surprise us and come to like the curves and algorithms we do. > Before the new curves can be used in browsers for certs, the > browser providers are going to have to be satisfied. …and we're going to need a signature algorithm. Our draft doesn't have one of those, and it seems what we're planning to do is do that in a second phase, as you address. > … But I don't want to do that in a way that makes it difficult to > move to EC certificates in the future. Agreed. > I don't accept that big endian is more error prone. The existing > code for X.509v3 crypto is all big endian. Changing that will > introduce a new code path and opportunity for error. Two points here. 1. There's a special circle of hell reserved for those who maintain X.509v3 code, where they debug ASN.1 parsers for all eternity! <g> Seriously though, if I want to dump some TLS code in the bin and rewrite it because it's too hairy, X.509 would be the first thing on the list. 2. I think that may well be an engineering decision, for the TLS WG or PKIX WG. What we've got here is the wire format of the raw function, and I continue to think that's the best approach to keep. TLS WG already discussed this and used that directly - little-endian and everything - for their Curve25519 key-exchange draft. I see no reason to second-guess that. They then also specified new curve point formats should be opaque octet strings to them, with no special treatment. Doesn't sound like they think endian-swapping for transport wire formats is worth it from an engineering perspective. It'd probably have to be PKIX WG who figure out how to put the wire format of whatever signature algorithm we - later - specify into whatever format they specify. If they want LE, or BE, or BCD, or ASCII base-10, or wrap it in ASN.1 with an OID and a ribbon on top, isn't that properly for them to decide? Either way, I don't think that's a big deal: if they really want to endian-swap, they can, but I'm not sure we should pre-empt them here. > Now it should be quite easy to add the new curves to the list. I > suspect that unless the browser providers are feeling really > generous, they will expect us to end of life our existing ECC > certs to get the new ones added. I can't speak for them of course, but that's not the impression I get from either them or CAs? We aren't _replacing_ NIST curves as far as I know in a near-term timescale, but providing a better alternative for the future. NIST seem to have much less sway with NGOs than previously. There will probably be a steady transition to using them, but, say, those who need FIPS (as above) may never be able to, unless NIST shadow our recommendations - which would honestly surprise me, but who knows? - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUyd2OAAoJEOyEjtkWi2t6yHwP/1zy2Bz6IvM9tdl+g3djxhii yfxFtdSUBBtCTWqFpvr+sZFkDUT/pdTR8QvX1ttdKqleJp7mzJTh8rToc3vgguCy ibM2tTOuk3tWcPzdzoiEMWdzKG/7Z1ecucMD9F7SeWiMiI8ebLA64i73tgiCAwZP A7lvpJ74D2v9iAQMhmNObUzeGguqkJR800gYgYi9VHaBkYIYRrtxyuhfwOES6WNW QVD66C168cyTsnOApqDuhVy7YRhYr11r/0d1pJC+hboP412O7+FYPJAZZDEaCTB4 3FzRgf+1x6PgPRu77BzoYAfrnm8mk42Yyo9BHHpPZtmmmULYakUj8IhVPZyeenYK M1x7m4gx6WZpeEJrzvac0FlVrOH6Bg3slGgL/aib6edXE6HQ6alK7wEPTl1//VQp R7bQC9bM16Ztcrc02FF76JNaZ46/ujdCYicJN8/HHGz3/QyCS8K0Fs8N5Jx/j1DX LXy5fRNZ/GcS7JRwuFnaaYiEb2Ng42ZW36fdLcWti7n8eR/E9gNODDZov/5B0/V9 jjIsar+25s3sikTzEQVYIZS0W/fuJCLSx+ZtblimPtOJ+33WOsWSgjD3eBuxXO1P DeTYGQLaEaEE5O4IcDao6xLt+CjoU5ZK3yZgNoihvzPReCqrGb2e//UfmSpv+D/5 So+7wv3rGDbnMwXLb+9/ =EfS3 -----END PGP SIGNATURE-----
- [Cfrg] big-endian short-Weierstrass please Dan Brown
- Re: [Cfrg] big-endian short-Weierstrass please David Gil
- Re: [Cfrg] big-endian short-Weierstrass please Daniel Kahn Gillmor
- Re: [Cfrg] big-endian short-Weierstrass please Dan Brown
- Re: [Cfrg] big-endian short-Weierstrass please Daniel Kahn Gillmor
- Re: [Cfrg] big-endian short-Weierstrass please Nico Williams
- Re: [Cfrg] big-endian short-Weierstrass please Alyssa Rowan
- Re: [Cfrg] big-endian short-Weierstrass please Tony Arcieri
- Re: [Cfrg] big-endian short-Weierstrass please Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] big-endian short-Weierstrass please Phillip Hallam-Baker
- Re: [Cfrg] big-endian short-Weierstrass please Alyssa Rowan
- Re: [Cfrg] big-endian short-Weierstrass please Stephen Farrell
- Re: [Cfrg] big-endian short-Weierstrass please Phillip Hallam-Baker
- Re: [Cfrg] big-endian short-Weierstrass please Daniel Kahn Gillmor
- Re: [Cfrg] big-endian short-Weierstrass please Hanno Böck
- Re: [Cfrg] big-endian short-Weierstrass please Dan Brown
- Re: [Cfrg] big-endian short-Weierstrass please Nico Williams
- Re: [Cfrg] big-endian short-Weierstrass please Watson Ladd
- Re: [Cfrg] big-endian short-Weierstrass please Phillip Hallam-Baker
- Re: [Cfrg] big-endian short-Weierstrass please Watson Ladd
- Re: [Cfrg] big-endian short-Weierstrass please Dan Brown
- Re: [Cfrg] big-endian short-Weierstrass please Nico Williams
- Re: [Cfrg] big-endian short-Weierstrass please Phillip Hallam-Baker
- Re: [Cfrg] big-endian short-Weierstrass please Yoav Nir
- Re: [Cfrg] big-endian short-Weierstrass please Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] big-endian short-Weierstrass please Nico Williams
- Re: [Cfrg] big-endian short-Weierstrass please Paul Hoffman
- Re: [Cfrg] big-endian short-Weierstrass please Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] big-endian short-Weierstrass please Phillip Hallam-Baker
- Re: [Cfrg] big-endian short-Weierstrass please Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] big-endian short-Weierstrass please Daniel Kahn Gillmor
- Re: [Cfrg] big-endian short-Weierstrass please Nico Williams
- Re: [Cfrg] big-endian short-Weierstrass please Phillip Hallam-Baker
- Re: [Cfrg] big-endian short-Weierstrass please Andrey Jivsov
- Re: [Cfrg] big-endian short-Weierstrass please Phillip Hallam-Baker