Re: [openpgp] SHA-x performance

ianG <> Wed, 12 August 2015 13:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B517A1B2D7E for <>; Wed, 12 Aug 2015 06:23:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hzX1CUgULiiQ for <>; Wed, 12 Aug 2015 06:23:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6652F1A8993 for <>; Wed, 12 Aug 2015 06:23:57 -0700 (PDT)
Received: from tormenta.local ( []) by (Postfix) with ESMTPSA id BBCDC6D76F; Wed, 12 Aug 2015 09:23:55 -0400 (EDT)
Message-ID: <>
Date: Wed, 12 Aug 2015 14:23:55 +0100
From: ianG <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>, <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [openpgp] SHA-x performance
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Aug 2015 13:23:59 -0000

On 12/08/2015 03:08 am, Peter Gutmann wrote:
> Werner Koch <> writes:
>> Do you have a suggestion on what CPUs from low to high end to do benchmarks
>> so to check which SHA variant is suitable?
> It'd be a longish list :-).  I'm also not sure how easy it'll be to get at
> them, this is all embedded-systems stuff so you can't just SSH into a box and
> run the tests.  In any case the most common is ARM Cortex M (and a few R), so
> any Cortex M3 (the example I gave was an STM32 at 180MHz which admittedly is
> the top end of the range, 100 or 80 Mhz would be another benchmark level, but
> then they're all ARMv7-M so you can extrapolate from one clock speed to
> another), then for PowerPC something like an MPC560x at 80 MHz (very common in
> industrial and automotive), a PIC32MX (MIPS32) at 60 MHz, and then for exotica
> maybe a NIOS II or MicroBlaze at 100 Mhz.  You don't really need to do dozens
> of variants since things mostly scale directly with clock speed, and in any
> case those are reasonably representative clocks, at least for the faster devices
> where power-saving isn't an issue.

To what extent are we accepting the embedded market as "our market" ?

Is this something that already exists in the sense that a lot of them 
are already doing OpenPGP signing for some purpose?  Is the process 
things like signed updates, or are people using OpenPGP to encrypt 
and/or sign requests to the devices?

Or, are we making a stab at the future:  "IoT will need security 
systems, and OpenPGP will be used to supply that, so we'd better make 
sure it fits on the rough template of devices."

To give a ludicrous counter-example, we could also optimise the future 
hash for smartcards.  That's another big market, why not?  I'd say this 
doesn't work mostly because the smartcard or tokens market is mostly 
closed, and systems are typically constructed to be tightly bound to the 
end-user application;  generic systems such as OpenPGP would find it hard.

Where do we draw the line?  Are embedded / IoT inside?