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

Hannes Tschofenig <> Fri, 27 June 2014 08:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2C7C71B2F2D for <>; Fri, 27 Jun 2014 01:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fizi-oB8rNlX for <>; Fri, 27 Jun 2014 01:58:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 391501B2AF4 for <>; Fri, 27 Jun 2014 01:58:32 -0700 (PDT)
Received: from [] ([]) by (mrgmx102) with ESMTPSA (Nemesis) id 0Mb31L-1XGCWU4AcF-00KhCh; Fri, 27 Jun 2014 10:58:30 +0200
Message-ID: <>
Date: Fri, 27 Jun 2014 10:58:48 +0200
From: Hannes Tschofenig <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7LFJwpuuAFEXdqoUkpjihQPGNXHadHDqo"
X-Provags-ID: V03:K0:1WhwaUNaJjidZEt+UtoyErHepavcKmGHYLl+4aI8h4CAGyNWCJt 7ilsDhhHZiM9RpRBdRUAA+d2bUQEg3yNBQrlpFnWIHGnuZKbzeZWTGHrEk153XYGqSQL++z WQf2uZ3s3KRwBuTLWUZsbBiWiFk7aNxigyhA8Kl7mCshYl3FdnDqfF26LOfbDtgi9Exp2Xk XElzV1yKH2G9SNAlaDimQ==
Cc: "" <>
Subject: Re: [TLS] Hardware Implementations .. Re: On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Jun 2014 08:58:34 -0000

Hi Joachim,

On 06/27/2014 10:21 AM, Joachim Strömbergson wrote:
> Aloha!
> Hannes Tschofenig wrote:
>> 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
>> 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)
> Great work and information! Have you done a write-up of the results? I'm
> very interested in info on the code size and data memory during operation.

No, I haven't created a write-up yet. I believe I should make take a
look at other curves first to have a reasonable comparison.

I will try to put something together for the upcoming IETF meeting
(since it might be relevant to the LWIG working group).

(Code size and RAM size is a bit tricky since there is some other stuff
that need to be compiled into the code to make it useful.)

>> (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.)
> So how did you do the random generation? Fixed values or some other
> mechanism?
This is probably more an issue of embedded systems (rather than the TLS
working group in general) but I had to put fixed values in there since I
didn't want to rely on the library that some other person wrote and a
hardware random number generator was only available with another board
but the core mbed libaries do not yet offer the API.

In a nutshell, I used fixed values.