Re: [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:58 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7C71B2F2D for <tls@ietfa.amsl.com>; Fri, 27 Jun 2014 01:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fizi-oB8rNlX for <tls@ietfa.amsl.com>; Fri, 27 Jun 2014 01:58:32 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 391501B2AF4 for <tls@ietf.org>; Fri, 27 Jun 2014 01:58:32 -0700 (PDT)
Received: from [192.168.131.143] ([80.92.115.50]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Mb31L-1XGCWU4AcF-00KhCh; Fri, 27 Jun 2014 10:58:30 +0200
Message-ID: <53AD3248.8000100@gmx.net>
Date: Fri, 27 Jun 2014 10:58:48 +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: joachim@secworks.se
References: <53AC97B8.2080909@nthpermutation.com> <53AD134E.9010903@akr.io> <53AD27B4.2060901@gmx.net> <53AD296C.40204@secworks.se>
In-Reply-To: <53AD296C.40204@secworks.se>
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==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/by_LQTAoaDrbApkCqKQVyvYgxzQ
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [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: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 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) https://mbed.org/handbook/mbed-FRDM-KL25Z
> 
>> - 0.047394 seconds for generating a Curve25519 key pair on a Cortex
>> M3 (LPC1768, 96MHz) https://mbed.org/platforms/mbed-LPC1768/
> 
> 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.

Ciao
Hannes