Re: [Cfrg] generic curves ... RE: big-endian short-Weierstrass please

Aaron Zauner <> Sat, 31 January 2015 14:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3D4A21A0373 for <>; Sat, 31 Jan 2015 06:50:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jtob5Nw1hlA1 for <>; Sat, 31 Jan 2015 06:50:10 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6D07F1A0154 for <>; Sat, 31 Jan 2015 06:50:10 -0800 (PST)
Received: by with SMTP id gm9so29315742lab.0 for <>; Sat, 31 Jan 2015 06:50:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=Eryg9C9sDum1JWzeiKflO7SG8tyi2/e43cUh+0y9BfM=; b=hvUkoaabsAweNKtewaOIODriE8Bffgw0hcGdpDsYqJa5uPfRxHakJ50j2SRuteq0e2 uOw4einBu/+azTL3/wrtedzBciDKaaBg+fEGyPlZbdCvDyKzV31nbUXk6QaSi8hkWEV1 AVxdEYn3Uu+D80zAYnOPkAXCyJ4KBi7GhUxBEHpwP1KmRLHC8plprpk9l+vHHubhNU7g 8d7F4sPWWZwV7KI6AZ0dryZbgaBP0EBVwpSQrT2LbWjckOoWPVX/HnBSWQ34JrBFhXQD KhXWcNcgfITPS4TFf8VClKpmvuBcFAXESf7RsjbkKqszt3M67OA9oBD5qTf+SKzgWzb4 Km4Q==
X-Gm-Message-State: ALoCoQkm3EOxbJiU4Rk6VMgbrb5Vu2sYd9nb3oceJRZPTEKYehGZO3AyA2gULXiFep3ZkfnWoFu1
X-Received: by with SMTP id e4mr11382618lab.62.1422715808667; Sat, 31 Jan 2015 06:50:08 -0800 (PST)
Received: from ?IPv6:2001:67c:1810:f055:c8d0:700b:d1a9:5303? ([2001:67c:1810:f055:c8d0:700b:d1a9:5303]) by with ESMTPSA id x1sm3319362lby.26.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 Jan 2015 06:50:07 -0800 (PST)
Message-ID: <>
Date: Sat, 31 Jan 2015 15:50:03 +0100
From: Aaron Zauner <>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Dan Brown <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="------------enig2808E605D0733B0889DE9F37"
Archived-At: <>
Cc: "''" <>
Subject: Re: [Cfrg] generic curves ... RE: big-endian short-Weierstrass please
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 31 Jan 2015 14:50:12 -0000

Dan Brown wrote:
> 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.


I read this as: we have this custom patented curves that we want to push
and want to use in TLS. Can we please? Use dkg's suggested private range.