Re: [openpgp] SHA-x performance

Peter Gutmann <> Fri, 14 August 2015 09:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 995BD1A710D for <>; Fri, 14 Aug 2015 02:30:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oDiF-sc8Oini for <>; Fri, 14 Aug 2015 02:30:29 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 823451A7013 for <>; Fri, 14 Aug 2015 02:30:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1439544629; x=1471080629; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=C+YN/S0NSvS6REaMNeesZJ4oS5+mbRSjqYxvZTGRrLI=; b=e/TrClhv3lm5Ugh6RC/RyjcknP68eL+8ZLvcRhprzxUXpEJduUU2jHGz qZZR1imRJZTBy04Eni+FMMvB91pTHGFHyoEy0EMBPGf7Vh13e6WbOU0O5 MK+YtEvLCCKpBPBD48OvqRfKiqBRPoNZHNe1qgedwBYOYk41bW1Y2XqxT /5bV+tpKDghk+4lE1EsZKVTCAlSi5Zh1APmG07JHg0tKIxhcwp3Uu1de3 7gZNJM7Ac3etoXB0SjvVDMP4IYXyDfbuL5uskIHYfaIe5OVMuEr9dOX0H jfoaWNtkG8Nmc4oRwj/2W1vXLdW3/PU4j8B3gzSAlM2Z7CoxP1ASrIF6C Q==;
X-IronPort-AV: E=Sophos;i="5.15,676,1432555200"; d="scan'208";a="35122966"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 14 Aug 2015 21:30:24 +1200
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Fri, 14 Aug 2015 21:30:24 +1200
From: Peter Gutmann <>
To: ianG <>, "" <>
Thread-Topic: [openpgp] SHA-x performance
Thread-Index: AQHQ1HVJQ9dFbQGKcEKa6BiYPQDA/J4HnlTQ///z3YCAA6wbrg==
Date: Fri, 14 Aug 2015 09:30:24 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>, <> <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Fri, 14 Aug 2015 09:30:34 -0000

ianG <> writes:

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

It's not a case of "now we want to target 8051's" but more a case of "the same
hardware that can currently employ PGP shouldn't be prevented from employing
it in the future because of a change to an overly heavyweight algorithm".
Switching from SHA-1 to SHA-256 isn't a big deal, but going to SHA-512 with
its order-of-magnitude slowdown over -256 is.

An example of a typical target device was the one mentioned in another post by
Yutaka Niibe, an STM32F103, which is a Cortex M3 that I mentioned earlier.  A
more recent, and also very popular one, is the M0 (released five years after
the M3, but with much more minimal capabilities, I'd set the minimum target at
an M3 in that if you want to be doing crypto you shouldn't be using an M0).

>Is this something that already exists in the sense that a lot of them are
>already doing OpenPGP signing for some purpose? 

Use of PGP in embedded is basically nonexistent, so it's more a case of "this
could be useful in the future".  The stuff will have to be secured in some
manner, and being able to present PGP as a candidate would be good.

(To put this into perspective, there's an apparently neverending stream of
checkbox-engineered security standards and best-practices for things like
smart meters where the developers are being asked to implement X.509 cert
handling, SCEP for cert enrolment, TLS for reporting, and SSH for remote
management, on an M0 realtime system (so no task can hold up the CPU for more
than, say, 10ms) with 4kB RAM and 32kB flash total.  Now admittedly PGP won't
fit into that either, but it's slightly less insane than the wishlists being
promulgated by industry groups.  I have no idea what developers are doing in
response to this disconnect from reality in the requirements, but I'm guessing
it'll provide fodder for Black Hat and Defcon talks for years to come).