[TLS] Hardware Implementations .. Re: On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 27 June 2014 08:13 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id BEDB61B278A for <tls@ietfa.amsl.com>; Fri, 27 Jun 2014 01:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lE_Q4Z0nRNzn for <tls@ietfa.amsl.com>; Fri, 27 Jun 2014 01:13:56 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F931A02DE for <tls@ietf.org>; Fri, 27 Jun 2014 01:13:29 -0700 (PDT)
Received: from [] ([]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MFu0Y-1WvSvx0fhe-00EtBv; Fri, 27 Jun 2014 10:13:27 +0200
Message-ID: <53AD27B4.2060901@gmx.net>
Date: Fri, 27 Jun 2014 10:13:40 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Alyssa Rowan <akr@akr.io>, tls@ietf.org
References: <53AC97B8.2080909@nthpermutation.com> <53AD134E.9010903@akr.io>
In-Reply-To: <53AD134E.9010903@akr.io>
X-Enigmail-Version: 1.5.2
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="60LrpnRTekCU1C8mfoQXhuj8m8oR9LH9l"
X-Provags-ID: V03:K0:yjRufLa2z/RupyRzdWZgSitVgPCoQeCOpDWOj7Fj8ExmFnfjYuF HjwdzZhq8Okyvl3/h8jelfu3vugQ8v4WlD9kMzuTKak9b1hkU+XYBhgIYAyfND3R1iPDhGN TGh3Ry1wHBpZH1gt1S41ffqXHuJSm2YZb5E9zbbryQX57rkNnni68FrfTLe7NScQ+h4oazb 7jMQeFFVBfR78ERitSHvA==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VBIVA65r-qyaX6VoGZwQqLzIEVs
Subject: [TLS] Hardware Implementations .. Re: On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jun 2014 08:13:59 -0000

It might be worth noting that many boards have dedicated chips for
cryptographic operations and even entire protocol stacks.

This, however, does not mean that they are hardware implementations.
They are software implementations running on separate chips. For
embedded systems the benefit of such approach is that the vendor of the
board can make the life of the embedded developer easier since they do
not have to search for a library and the runtime of the code can be
better controlled (particularly relevant if there are some real-time
related requirements to consider).

Based on the discussions at the IRTF interim meeting a little while ago
I took the Curve25519 code and ported it to mbed (the online development
platform ARM provides, see https://mbed.org).

I wanted to know how long it takes to generate key pairs since this is
one of the most performance-demanding operations. To my surprise it was
rather fast:

 - 0.278821 seconds for generating a Curve25519 key pair on a Cortex M0
(FRDM-KL25Z, 48MHz)

 - 0.047394 seconds for generating a Curve25519 key pair on a Cortex M3
(LPC1768, 96MHz)

(Note that I did not include the calculation of the random numbers in
those numbers since it will depend on a variety of factors, including
the hardware capabilities of the used board.)

These are processors used in the Internet of Things environment.

I will have to do more tests using different processors and different
curves [but I have to start somewhere].

On 06/27/2014 08:46 AM, Alyssa Rowan wrote:
> Hardware implementations always lag new technologies: ARMv8 only just
> got SHA-256, and Intel and AMD don't have anything which specifically
> accelerates any crypto except AES.