Re: [Cfrg] generic curves ... RE: big-endian short-Weierstrass please
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Thu, 29 January 2015 23:30 UTC
Return-Path: <dkg@fifthhorseman.net>
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 BF5801A1B7B for <cfrg@ietfa.amsl.com>; Thu, 29 Jan 2015 15:30:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 G9lbb3THS4No for <cfrg@ietfa.amsl.com>; Thu, 29 Jan 2015 15:30:02 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDCC1A88AF for <cfrg@irtf.org>; Thu, 29 Jan 2015 15:30:02 -0800 (PST)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 3B6EAF984; Thu, 29 Jan 2015 18:29:59 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 17F67201F8; Thu, 29 Jan 2015 18:30:08 -0500 (EST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Dan Brown <dbrown@certicom.com>, "'nico@cryptonector.com'" <nico@cryptonector.com>, "'ynir.ietf@gmail.com'" <ynir.ietf@gmail.com>
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5D45067@XMB116CNC.rim.net>
References: <810C31990B57ED40B2062BA10D43FBF5D45067@XMB116CNC.rim.net>
User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Thu, 29 Jan 2015 18:30:08 -0500
Message-ID: <87h9v9b1xb.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/KvumFHeRcXgxCjCSStGynJlY2QU>
Cc: "'cfrg@irtf.org'" <cfrg@irtf.org>
Subject: Re: [Cfrg] generic curves ... RE: 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 23:30:05 -0000
On Thu 2015-01-29 17:09:18 -0500, Dan Brown wrote: > The current set of TLS named curves includes NIST (and some SECG?) and > Brainpool curves, right? Is there some of these current curves that TLS plans > to disallow? There is already a plan in TLS to deprecate the use of the smaller curves, similar to the cutoff you describe below. > I'd suggest that TLS and IETF protocols only keep (EC)DH groups with at least > 2^256 - S elements (for small S), but grandfathering in Curve25519, P256, (and > maybe secp256k1, if there ???). In other words, smaller curves, 163 bits, 192 > bits, and so on, could be removed. Actually, this should be redundant, as > long protocols match symmetric key sizes ... > > By the sounds of it, TLS doesn't yet have a good way to negotiate curves on > the fly (even CA / server pre-validated curves?), yet. As i've already said on-list today, If both peers already know about some custom curve they want to use, they should take advantage of TLS's "private use range" and negotiate their preferred custom curve there. This requires no external vetting of curves or point formats or anything; just pre-agreement between peers about what they want the codepoints within the private-use range to mean. I have yet to hear a reason why this isn't acceptable for anyone who needs custom curves between pre-arranged peers, so i'll stop repeating it. If it doesn't work for you, please explain why. --dkg
- [Cfrg] generic curves ... RE: big-endian short-We… Dan Brown
- Re: [Cfrg] generic curves ... RE: big-endian shor… Daniel Kahn Gillmor
- Re: [Cfrg] generic curves ... RE: big-endian shor… Paul Hoffman
- Re: [Cfrg] generic curves ... RE: big-endian shor… Dan Harkins
- Re: [Cfrg] generic curves ... RE: big-endian shor… Aaron Zauner
- Re: [Cfrg] generic curves ... RE: big-endian shor… Kurt Roeckx
- Re: [Cfrg] generic curves ... RE: big-endian shor… Watson Ladd
- Re: [Cfrg] generic curves ... RE: big-endian shor… Paterson, Kenny
- Re: [Cfrg] generic curves ... RE: big-endian shor… Kurt Roeckx
- Re: [Cfrg] generic curves ... RE: big-endian shor… Phillip Hallam-Baker