Re: [Cfrg] Hardware requirements for elliptic curves

Johannes Merkle <> Thu, 04 September 2014 12:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7E2151A889C for <>; Thu, 4 Sep 2014 05:56:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.868
X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GGHGCJnnQ7i0 for <>; Thu, 4 Sep 2014 05:56:24 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D37B31A8893 for <>; Thu, 4 Sep 2014 05:56:22 -0700 (PDT)
Received: from localhost (alg1 []) by (Postfix) with ESMTP id DE58B1A008B; Thu, 4 Sep 2014 14:56:16 +0200 (CEST)
X-Virus-Scanned: by secunet
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id c2Oiww5Yelxo; Thu, 4 Sep 2014 14:56:08 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTP id 0BCF81A0088; Thu, 4 Sep 2014 14:55:17 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id; Thu, 4 Sep 2014 14:55:20 +0200
Message-ID: <>
Date: Thu, 04 Sep 2014 14:55:20 +0200
From: Johannes Merkle <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Michael Hamburg <>, Alyssa Rowan <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
Subject: Re: [Cfrg] Hardware requirements for 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: Thu, 04 Sep 2014 12:56:26 -0000

Michael Hamburg wrote on 02.09.2014 18:31:
> I agree with Alyssa that hardware performance isn’t our concern here.

I disagree with this oversimplification. Currently, the fraction of TLS implementations based on HW is relatively
small but not negligible. And in the future it will increase:

1. Heartbleed has shown that it is dangerous to keep private keys in software. Hopefully, this lesson has been learned.

2. There are security critical infrastructures emerging, where TLS will be used with hardware crypto
implementations. Examples are car2car and car2X, health care infrastructures, smart meter,
e-government communications services.

3. In the foreseeable future, we will see a huge number of constrained devices in the IoT potentially deploying TLS
(e.g. for home automation, sensor networks).

Furthermore, other IETF protocols are well within the scope of our effort. (As Kenny wrote in his announcement of the
current effort "We regard this as a major work item for CFRG and one where CFRG can provide real value to the TLS WG
and the IETF more widely.") For IPSec, there is indeed a significant number of implementations based on smart cards or
small HW crypto modules (for instance from my employer).