Re: [Cfrg] Requirements for curve candidate evaluation update

Phillip Hallam-Baker <> Thu, 14 August 2014 02:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2732B1A074C for <>; Wed, 13 Aug 2014 19:39:39 -0700 (PDT)
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 OnvU8NFdRtOK for <>; Wed, 13 Aug 2014 19:39:38 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3DA61A0747 for <>; Wed, 13 Aug 2014 19:39:37 -0700 (PDT)
Received: by with SMTP id s7so462400lbd.8 for <>; Wed, 13 Aug 2014 19:39:36 -0700 (PDT)
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=//CQjwG4qB0Bg6RDdeMRcuhNLIX9/iPUQkmqKxaDW8Q=; b=U1GU6R8bBolBOtuxpIsiH8gjJM5yE0WBbzPN01es11y/KexR5vXw5F4DenhZXskhp5 cy4DizklPkPJqtB6sE9PsoxQciqpMTMaci6N6BKyZDjQcrKzVnM5YhK5ZYyaboEgEhWl wwdlT7rCmrNEEkgi18Dnkg91x4sieMd1QLnIAjvd71WwRIzmbv6XSk47eOfxvZORl/qE 2qSwo0/HVmDD3BID9EjE1spe5YIQhs8c54BKQYwl4oEgkCLSJQjtkPINXSeh/xbOA4c9 09kmxJQ9ZZIaONWitJSYDobq5eBEfc1uBO1qbzcI4IDOxFRodPjZFIaSKGi3ohYS9aay RlWQ==
MIME-Version: 1.0
X-Received: by with SMTP id j5mr1644318lae.38.1407983976118; Wed, 13 Aug 2014 19:39:36 -0700 (PDT)
Received: by with HTTP; Wed, 13 Aug 2014 19:39:35 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Wed, 13 Aug 2014 22:39:35 -0400
X-Google-Sender-Auth: SEGMBVe_JdsKbo7TcC4IQoZ1L3k
Message-ID: <>
From: Phillip Hallam-Baker <>
To: "Salz, Rich" <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [Cfrg] Requirements for curve candidate evaluation update
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, 14 Aug 2014 02:39:39 -0000

On Wed, Aug 13, 2014 at 10:27 PM, Salz, Rich <> wrote:
>> Long term signature keys have to be generated and stored in HSMs
> So EDH keys do not, and therefore do not need HSM requirements, right?

I don't see a large field of established use that would make
availability of HSMs a gating factor for EDH. But obviously someone
could come up with one.

What I am trying to do here is to pare down the set of requirements
WITHOUT throwing out any that could be show stoppers or gating

The use of ECC to date in open standards based systems is so
insignificant that we really should not think twice about blowing it
all up and starting from scratch. But if we do that then someone has
to tell the HSM vendors where we are going and some of them have to
sign on.

Not wanting to make a big fuss on the HSM requirement but it is
definitely a potential gating factor. Using the same curve model for
encryption and signature does not interest me in the slightest. I
cannot see that as being a necessary requirement, it is just someone
wanting things to be tidy.

The only good reason to go to ECC right now is to get a bigger safety
margin on your crypto. And it really makes no sense to want to do that
and be shooting yourself in both feet by using signature keys for
encryption or vice versa.

The keys are plenty small enough to have separate encryption and
signature keys. It would be no bad thing if we made it algorithmically
impossible to attempt that type of abuse.

I do want to junk the NIST curves though but not for the reason folk
think. The big problem with ECC is the sheer length of time we have
been waiting. Deployment is going to continue to be slow unless we get
some sort of starting gun. One possibility is that the starting gun is
breaking RSA1024 but having a new set of NSA-free curves agreed by
IETF is good as well.