Re: [openpgp] SHA-x performance

ianG <iang@iang.org> Wed, 12 August 2015 15:11 UTC

Return-Path: <iang@iang.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425F31A8A47 for <openpgp@ietfa.amsl.com>; Wed, 12 Aug 2015 08:11:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 1DNhjVJ_HlfR for <openpgp@ietfa.amsl.com>; Wed, 12 Aug 2015 08:11:45 -0700 (PDT)
Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6FB1A8A45 for <openpgp@ietf.org>; Wed, 12 Aug 2015 08:11:45 -0700 (PDT)
Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 83D9E6D75C; Wed, 12 Aug 2015 11:11:44 -0400 (EDT)
Message-ID: <55CB6230.1050508@iang.org>
Date: Wed, 12 Aug 2015 16:11:44 +0100
From: ianG <iang@iang.org>
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
To: openpgp@ietf.org
References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <sjma8tztbgo.fsf@securerf.ihtfp.org> <CAMm+Lwj7SxXTn+KD-eQSeZHwJB36tCgD1t0bodVsp3ovOaZ8mw@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> <87io8lpzu4.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4AD7F8E@uxcn10-5.UoA.auckland.ac.nz> <87mvxxenss.fsf_-_@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4AD8086@uxcn10-5.UoA.auckland.ac.nz> <878u9hefcs.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4AD85CC@uxcn10-5.UoA.auckland.ac.nz> <55CB48EB.5090403@iang.org> <CAMm+LwicXPwCdysXLyHHCmjvpCzS-jvjFFjVr+MVdijHd50NYQ@mail.gmail.com>
In-Reply-To: <CAMm+LwicXPwCdysXLyHHCmjvpCzS-jvjFFjVr+MVdijHd50NYQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/Fhmc5fCdEiIKopTYFJRBQqbkCR0>
Subject: Re: [openpgp] SHA-x performance
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Aug 2015 15:11:47 -0000

On 12/08/2015 15:13 pm, Phillip Hallam-Baker wrote:
>
>
> On Wed, Aug 12, 2015 at 9:23 AM, ianG <iang@iang.org
> <mailto:iang@iang.org>> wrote:
>
>     On 12/08/2015 03:08 am, Peter Gutmann wrote:
>
>         Werner Koch <wk@gnupg.org <mailto:wk@gnupg.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