[Cfrg] generic curves ... RE: big-endian short-Weierstrass please
Dan Brown <dbrown@certicom.com> Thu, 29 January 2015 22:09 UTC
Return-Path: <dbrown@certicom.com>
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 596671A8878 for <cfrg@ietfa.amsl.com>; Thu, 29 Jan 2015 14:09:37 -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 lafNcYHFAZ8m for <cfrg@ietfa.amsl.com>; Thu, 29 Jan 2015 14:09:27 -0800 (PST)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7E09A1A8876 for <cfrg@irtf.org>; Thu, 29 Jan 2015 14:09:26 -0800 (PST)
Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 29 Jan 2015 17:09:20 -0500
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT105CNC.rim.net ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.03.0210.002; Thu, 29 Jan 2015 17:09:19 -0500
From: Dan Brown <dbrown@certicom.com>
To: "'nico@cryptonector.com'" <nico@cryptonector.com>, "'ynir.ietf@gmail.com'" <ynir.ietf@gmail.com>
Thread-Topic: generic curves ... RE: [Cfrg] big-endian short-Weierstrass please
Thread-Index: AdA8AesG7iT5/NihS7+0fk6r2j3zuw==
Date: Thu, 29 Jan 2015 22:09:18 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5D45067@XMB116CNC.rim.net>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.252]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0082_01D03BE6.512EE8D0"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/Odf8RvMu0c2vxD96sCN0xZESRMg>
Cc: "'cfrg@irtf.org'" <cfrg@irtf.org>
Subject: [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 22:09:38 -0000
New thread name ... should have done so earlier. When TLS asked CFRG for new curves, I didn't interpret that to mean that generic curves would be banned. Banishing generic curves adds slightly more weight to the TLS request, because users cannot easily opt out of the chosen few elite curves. Upon further reflection, I think CFRG already spent enough time to find an answer that weightier question, and in particular, I'll keep my vote the same. 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? 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. My proposal for generic curves presumes that the generic elliptic curve domain parameters are authenticated, i.e. Alice and Bob are not duped into using a curve that they don't agree upon, and validated, perhaps in advance. Actually, the old standards, SEC1, X9, etc., pretty much make this a requirement before doing ECC. Having tried to maintain a couple of these old standards, I sometimes take such things for granted. Anyway, if TLS is unable to only achieve this authentication by using vetted and named curves, then my generic curve proposal would not apply to TLS. Best regards, Dan PS While we're tracking thread discussions, I remember suggesting to one the lists last year that TLS add for support generic curves, but I was mistakenly confusing TLS and PKIX: it was PKIX that had restricted named-curves only. I don't recall this much discussion in response, other a couple people correcting my mistake. If it was pointed out at that time that TLS was unable to securely support generic curves, then I apologize for forgetting.
- [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