ietf-openpgp
[Top] [All Lists]

Re: [openpgp] SHA-x performance

2015-08-12 10:11:51
On 12/08/2015 15:13 pm, Phillip Hallam-Baker wrote:


On Wed, Aug 12, 2015 at 9:23 AM, ianG <iang(_at_)iang(_dot_)org
<mailto:iang(_at_)iang(_dot_)org>> wrote:

    On 12/08/2015 03:08 am, Peter Gutmann wrote:

        Werner Koch <wk(_at_)gnupg(_dot_)org <mailto:wk(_at_)gnupg(_dot_)org>> 
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

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp