Re: [openpgp] SHA-x performance

[ianG <[e-mail]>]

On 12/08/2015 15:13 pm, Phillip Hallam-Baker wrote:
>
>
> On Wed, Aug 12, 2015 at 9:23 AM, ianG <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On 12/08/2015 03:08 am, Peter Gutmann wrote:
>
>         Werner Koch <[e-mail] <mailto:[e-mail]>> 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?
>
>
> If we are picking algorithm suites then we should look at the cases
> where the choice might matter rather than when it does not.
>
> IOT looks set to create a demand for an absolutely minimal cryptographic
> suite. One signature algorithm, one exchange algorithm, both on the same
> curve, one authenticated encryption mode, one digest/pseudorandom function.
>
> That suite is going to be the one that finds its way into hardware
> accelerators and those are in turn the sort of things that are going to
> be found as standard cell and on smartcards and such.
>
> So looking at a five year horizon, that is the set that is interesting.


Yes I entirely agree, that interesting discussion exists.  Is that what 
we are doing here, though?

Are we rewriting OpenPGP so we can turn on the lightbulb?

Personally, I see a huge leap here.  OpenPGP isn't suitable/designed at 
all for that application(s) / market(s).



iang