Re: [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves

Andy Lutomirski <> Wed, 16 July 2014 15:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ABB451B2BA6 for <>; Wed, 16 Jul 2014 08:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SB_bDRa5Qv4B for <>; Wed, 16 Jul 2014 08:48:47 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA9211B2A93 for <>; Wed, 16 Jul 2014 08:48:46 -0700 (PDT)
Received: by with SMTP id v6so530189lbi.39 for <>; Wed, 16 Jul 2014 08:48:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=SoAEcomANKGM9Y43SLI669zEkUGm2Z+kmvRN7NzGn80=; b=BdW3F5u2+KurL8JBaKg0/gYzdl7fPpuPKd5SaqyVLZoCtTXDAwsUNwlM648HebclSE /DHGx9T3vG9e+Ox8O7DxaWPRUnpBsX/x9QuUAhRRDXk8KKc78jC+46ccAjXiphFrIifJ B4mBJXMBWDQigWwz3m81A+Z4FgU6/GPk/QDF0oAd+321Rc8wSEjT2Sw0S6q7LJJFhoy3 ue2lmBEvX5lcNVTWidI+uNiFHZ0j4lm9tArOOF0+H0h2g0hAtQpWjJ99z87tbY2oAacA wgE4UEwED+8TXtJTMdfkmH16Si5NQX0hWtOpsEAEeSzMaGYXuJXydEHH5t4yKulxXxcM vXaw==
X-Gm-Message-State: ALoCoQkIiqUjHt8qtUtvgOZJguj4RPoTOeG4EbQnXDJqbZeuyN8l2kPC43YQwR/twNWjuLhTAwda
X-Received: by with SMTP id a10mr24783406lbj.11.1405525725135; Wed, 16 Jul 2014 08:48:45 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 16 Jul 2014 08:48:25 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Andy Lutomirski <>
Date: Wed, 16 Jul 2014 08:48:25 -0700
Message-ID: <>
To: "Joseph Salowey (jsalowey)" <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves
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: Wed, 16 Jul 2014 15:48:48 -0000

On Wed, Jul 16, 2014 at 8:35 AM, Joseph Salowey (jsalowey)
<> wrote:
> On Jul 14, 2014, at 6:11 PM, Watson Ladd <> wrote:
>> On Jul 14, 2014 12:49 PM, "Paterson, Kenny" <> wrote:
>>> Dear CFRG,
>>> CFRG has received a formal request from the TLS Working Group for
>>> recommendations for new elliptic curves. Specifically, the TLS WG would
>>> like CFRG to recommend:
>>> - Curves suitable for both key establishment and digital signature
>>>  (though the same curves need not be used for both purposes).
>>> - One proposed curve or set of curves at the following security
>>>  levels: 128-bit (~256-bit curve) and 256-bit (~512 bit curve).
>>>  192-bit security is optional.
>> I would like these to be taken as minimums. There is no reason
>> Curve4417 should not be used for 192 bit security
>> or Goldilocks448 if performance is acceptable.
>> I am not sure that 512 bits is needed: the NSA only uses P-384 for Top
>> Secret data. Perhaps this is an area where the
>> TLS WG can do some more thinking about what they want to see.
> [Joe] We've received a few comments about this offline so I want to clarify on desired strengths. TLS supports 256-bit symmetric key ciphers and we want to have recommended curves to match this key strength.  We leave it up to the CFRG to determine what ECC key strengths are appropriate above 128-bit symmetric key strength.  It is also not necessary that the recommendation for higher strength curves be delivered at the same time, it would be OK to deliver a recommendation for the 128-bit curves before the higher strength curves.

IIRC there's a reasonable argument for using 256-bit symmetric ciphers
with lower-strength curves.  There are brute-force attacks that can
break a small, random fraction of many 128-bit symmetric keys much
more quickly than any specific key could be broken, but I haven't
heard of similar attacks against ECDH.