Re: [Cfrg] ECC reboot (Was: When's the decision?)

Ilari Liusvaara <> Thu, 23 October 2014 12:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0CC2B1A916A for <>; Thu, 23 Oct 2014 05:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wBlYdvQ9S0oA for <>; Thu, 23 Oct 2014 05:01:44 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95D351ACEA8 for <>; Thu, 23 Oct 2014 05:01:43 -0700 (PDT)
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id 7962B69A15; Thu, 23 Oct 2014 15:01:40 +0300 (EEST)
Date: Thu, 23 Oct 2014 15:01:40 +0300
From: Ilari Liusvaara <>
To: "Paterson, Kenny" <>
Message-ID: <20141023120139.GA14813@LK-Perkele-VII>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <>
Cc: "" <>
Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?)
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, 23 Oct 2014 12:01:46 -0000

On Thu, Oct 16, 2014 at 04:08:18PM +0000, Paterson, Kenny wrote:
> Our first task should be to finalise the requirements that we will use to
> guide the selection process. I think we are close, with a couple of
> outstanding issues:
> 1. Amount of "wiggle room" that should be permitted.

Barring unforseen new way to implement base field math, there will
not be much wiggle room if performance is important consideration
and curve parameters are choosen minimally.

Heck, just see the amount of problems trying to find truly high-
performance curve near 384 bits.

> 2. A more nuanced set of hardware requirements.

Quite blunt, but: Hardware implementations are no consideration.

- This is for IETF TLS, and vast majority of endpoints are software.
- Software-optimized curves are not too bad for most hardware.
- And if they are too bad for some specialized kind of hardware,
  there already are more suitable curves in TLS.
- The kind of hardware needing such curves should not be
  contacting random peers, so making those peers capable of
  dealing with the necressary curves is feasible.