Re: [Cfrg] big-endian short-Weierstrass please

Phillip Hallam-Baker <> Thu, 29 January 2015 18:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B0E541A0368 for <>; Thu, 29 Jan 2015 10:18:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F4IydBGdOxtI for <>; Thu, 29 Jan 2015 10:18:46 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F37F01A0019 for <>; Thu, 29 Jan 2015 10:18:45 -0800 (PST)
Received: by with SMTP id z12so31088278lbi.7 for <>; Thu, 29 Jan 2015 10:18:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=e8fEwQJpSS/qnnPG3P2iM4eVxso1rwSFlSdVkekQKX0=; b=M9yCN6bqkS4ujha3JsYcuOT7pj5U0AeQLQcQe4wVIAHNRYXQF2BgcmnTzsiHC1Eysc UyuLW1D7QH1ebZa1aNyuBZQKwJrRk8PO4qIofvymhC1jl4c77m3HutK2fEoapGSMwxWJ +xPLOfioEKHBDBD1z5ZqyTgNoIaIqoUHC/aOLOUg+0FC9SJaVCW49nhWXsxfvLG8W7Mv +aREFYjfimrwcv8UNoVDfiHxwp7gG3RX0BKAtTcrRWgHMJ26HmH2JfTY4b2IWUwV6LeY vKzQTfA5dRwgjfWaTPDL3XRKFiN40sy2qlSiTYoMqMzfvDBqAmnIj3RohbWWyYUUAyDh oF3Q==
MIME-Version: 1.0
X-Received: by with SMTP id i5mr2382075lbj.49.1422555524487; Thu, 29 Jan 2015 10:18:44 -0800 (PST)
Received: by with HTTP; Thu, 29 Jan 2015 10:18:44 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <20150128231006.GJ3110@localhost> <> <> <> <>
Date: Thu, 29 Jan 2015 13:18:44 -0500
X-Google-Sender-Auth: t9fPJRQpEXUj8WA7RvjX1J45qfQ
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Watson Ladd <>
Content-Type: multipart/alternative; boundary="001a11c36c8cb5e127050dce8454"
Archived-At: <>
Cc: "" <>
Subject: Re: [Cfrg] 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: Thu, 29 Jan 2015 18:18:47 -0000

On Thu, Jan 29, 2015 at 12:50 PM, Watson Ladd <> wrote:
> > More importantly, I can't use your curves unless you can prove to me
> that they are secure. And the fact we are having trouble doing that in this
> group proves that it is not possible to achieve that in a protocol.
> We are not having trouble with that  in this group. Nobody disputes that
> any of the proposed curves are secure, or the details of generation.
> Instead, we're arguing about endiannes. I've tried to gather which primes
> everyone wants in one list, crickets.  Tony Arceli posts about signatures,
> 5 messages. Big v. Little, 40.
> Of course a malicious party can leak whatever you send them.
What I meant is that we had great difficulty in choosing curve parameters
that were not suspect so we developed objective criteria that effectively
removed the 'malicious curve' issue.

At this point I am pretty certain that I will not want to use my existing
crypto boxes for the new curves. I certainly don't want my keys for the
algorithms we chose for their constant time implementation friendliness
being implemented on legacy hardware.

I am not keeping score here, but my understanding is that we have a rough
consensus for P255 for the performance curve as it is as near as damnit 256
bits, very fast and has a lot of deployment support. Arguing over a single
bit seems illogical for a performance curve that is going to be used in TLS
for ephemeral encryption, particularly if we can fix the TLS key agreement
algorithm so that ephemeral agreed keys are always at least as random as
both the master key and the ephemeral inputs.

The ridiculously high assurance prime is a different matter. Perhaps what
CFRG should do is to choose both P512 curve and P448.

Curves are a different matter... I doubt that it really matters very much
and the differences in speed are likely to turn out to depend on whose
hardware is used.

Easiest to explain is probably the best criteria.