Re: [Cfrg] Curve manipulation, revisited

Adam Langley <> Thu, 25 December 2014 21:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 62CD61A887A for <>; Thu, 25 Dec 2014 13:05:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 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, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g4Q4bCfF5tyv for <>; Thu, 25 Dec 2014 13:05:30 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA7891A8874 for <>; Thu, 25 Dec 2014 13:05:29 -0800 (PST)
Received: by with SMTP id s18so8312763lam.16 for <>; Thu, 25 Dec 2014 13:05:28 -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=0oYfvOnCfwInncqW35wCQZAwHVeyU6f/mQIYUO7r0Hg=; b=ksENiRUfNPQiq0Qt6rLF662QwVhXDe1UzCVkq7qM7ebNcdDchuKzq6V7lIgtBJgA9M sUbIlFIB8ByiwEBIrVdfFo4SE8DYkTSyDZhAiZ9JQ9dWkwB7gCrV01H7TO7HTTb4tuRm SNX/39bn3XlzF6eyVpKhfty5LjK9LKKemzBnKciqk294IihIsP3OH9mHggeo5zJcAgtr 9T1fFLaXKQhYfyTARa39q8MPTkq+1ZGu1ontTyUREb2Xnpq3+ycoRIM2XwZRvu2xGFpN u4gQGqu/W4cc19qvmmSfB0UA7M1P63hJc3grp4LJskK+Vzf098DYcedH2xc6j+EeJN55 23nA==
MIME-Version: 1.0
X-Received: by with SMTP id ci1mr34778331lad.67.1419541528409; Thu, 25 Dec 2014 13:05:28 -0800 (PST)
Received: by with HTTP; Thu, 25 Dec 2014 13:05:27 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Thu, 25 Dec 2014 21:05:27 +0000
X-Google-Sender-Auth: J_xVyXnSUwMCHKv8b5fX_Wyz74U
Message-ID: <>
From: Adam Langley <>
To: David Gil <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [Cfrg] Curve manipulation, revisited
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, 25 Dec 2014 21:05:31 -0000

> I don't think this is quite right. Imagine we could improve the square
> root in Pollard rho to cube root via some algebraic geometry. Then
> 255/3=85, but 448/3=150. Even ignoring the possibility of algorithmic
> improvements, progress in computing power may mean data that has to be
> confidential for centuries needs a larger curve. The NSA did pick P384
> for a reason.

If we are positing a cube root algorithm for discrete-log, can't we
posit a 4th root one?

But, yes, there is a possibility of an attack that's *just* right:
weak enough not to break a larger curve but strong enough to break a
smaller one. On the other hand, each additional curve dilutes
implementation resources and implementation bugs happen. I'm judging
that the risk of a bug due to the additional curve is larger than the
benefit of hedging against that specific sort of analytic breakthough.

And, if you want to keep data safe for centuries, isn't post-quantum a

On Thu, Dec 25, 2014 at 8:38 PM, David Gil <> wrote:
> In particular, w.r.t. Yahoo's eventual release of an End-to-End
> messaging extension, we will generate EC keys for extension users
> on a curve subgroup with log2(#K) >= 376. The additional computational expense is, frankly, negligible.

I think my argument here is the same as above. (Although, in this
situation, you would have the advantage of being able to use the
simplest, clearest code possible because performance isn't a concern.)

> It's absurd to ignore the fact that the organization with the most mathematicians working on ECC[^fbfw] does not trust a bit-length
> 256 curve for data they consider important. See [NSA Suite B
> Cryptography][suiteb].

TOP SECRET just needed to have a bigger number than SECRET :)



Adam Langley