Subject: [openpgp] Version 5 key and fingerprint proposal

From: Werner Koch <[email-masked]>
Date: Tue, 07 Mar 2017 18:48:05 +0100

Hi!

Find my proposal for a V5 key and a new fingerprint scheme below and
also with a colored diff at

  <https://gitlab.com/openpgp-wg/rfc4880bis/commit/ba4f884c6d5483071d6adbc1e43978b60980440a>

Note that the patch builds upon

  commit e5a0caef2d5cc291118db58a477d3c034b0997cc
  Author: Werner Koch <[email-masked]>
  Date:   Tue Mar 7 11:52:27 2017 +0100

    Factor key algorithm specific parts out to a new section.
    
    Aside from having the public and secret key parameters now close
    together, this editorial change will make it easier to add new a new
    key packet format and prepares for algorithms which can't be described
    by a list of MPIs (which is actually already the case for ECC keys).

Comments?

Shalom-Salam,

   Werner

=====
From ba4f884c6d5483071d6adbc1e43978b60980440a Mon Sep 17 00:00:00 2001
From: Werner Koch <[email-masked]>
Date: Tue, 7 Mar 2017 17:48:15 +0100
Subject: [PATCH] Specify a v5 key version and a new fingerprint scheme.

The v5 key version is introduced to
  a) to trigger the use of the new fingerprint scheme,
  b) to prepare for algorithms which need keys larger than 64k,
  c) to ease parsing of unknown algorithms.

The fingerprint algorithm uses SHA-256 because
  a) 32 octets are sufficient for a fingerprint
     (#include "640k-ram-will-always-be-enough.joke"),
  b) SHA-256 is well matured and widely available,
  c) SHA-256 is faster than SHA-512 on embedded platforms,
  d) implementations need to support SHA-256 anyway because it is
     the commonly used hash algorithms for signatures.

Although the fingerprint is specified at full length it is truncated
to 25 octets for purposes of the OpenPGP spec.  This is so that
signatures are not too much enlarged without a good reason.

A human readable representation of the fingerprint is not given
because that was never done in OpenPGP.  Implementations may for
example use

  1122334455 6677889900 aabbccddee ff00112233 4455667788
or
  11223 34455 66778 89900 aabbc cddee ff001 12233 44556 67788

to show fingerprints.

The Key ID is still defined because the 64 bits do not pose a problem
when used to selecting the decryption key.  The leftmost 64 bits of
the fingerprint are used (v4 uses the rightmost).

Aside from a few editorial changes the actual changes are:

* Revocation key and Issuer Fingerprint:

  - For a V5 key the 25 leftmost octets are used.

* Public key packet:

  - New four-octet count of the public key material.
    This is to ease parsing.

* Secret key packet

  - S2K Usage octet MUST NOT be 255.
    That is V5 keys require the SHA-1 checksum but
    we may want to drop this in favor of an AEAD mode.

  - New one-octet count of the S2K parameters.
    This is to ease parsing.

  - New four-octet count of the secret key material.
    This is to ease parsing.

* Key IDs and Fingerprint

  - The V5 fingerprint uses SHA-256

  - The magic header is changed from 0x99 + two-octets length header
    to 0x9a = four-octet length header.  The four-octet public key
    material count is inserted.

* EC DH Algorithm

  - For the 20 octets representing a recipient in the KDF parameters
    the v5 fingerprint truncated to 20 octets is used.
---
 middle.mkd | 98 +++++++++++++++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 81 insertions(+), 17 deletions(-)

diff --git a/middle.mkd b/middle.mkd
index 462730b..1cd9f86 100644
--- a/middle.mkd
+++ b/middle.mkd
@@ -1279,8 +1279,11 @@ #### {5.2.3.14} Regular Expression
 
 #### {5.2.3.15} Revocation Key
 
-(1 octet of class, 1 octet of public-key algorithm ID, 20 octets of
-fingerprint)
+(1 octet of class, 1 octet of public-key algorithm ID, 20 or 25 octets
+of fingerprint)
+
+V4 keys use the untruncated 20 octet fingerprint; V5 keys use the
+right truncated 25 octet fingerprint
 
 Authorizes the specified key to issue revocation signatures for this
 key.  Class octet must have bit 0x80 set.  If the bit 0x40 is set, then
@@ -1629,7 +1632,9 @@ #### Issuer Fingerprint
 64 bits of the fingerprint.
 
 Note that the length N of the fingerprint for a version 4 key is 20
-octets.
+octets.  For a version 5 key N is 25 and the fingerprint is right
+truncated to 25 octets.
+
 
 ### {5.2.4} Computing Signatures
 
@@ -1888,6 +1893,27 @@ ### {5.5.2} Public-Key Packet Formats
   * A series of values comprising the key material.  This is
     algorithm-specific and described in section XXXX.
 
+The version 5 format is similar to the version 4 format except for the
+addition of a count for the key material.  This count helps parsing
+secret key packets (which are an extension of the public key packet
+format) in the case of an unknown algoritm.  In addition, fingerprints
+of version 5 keys are calculated differently from version 4 keys, as
+described in the section "Enhanced Key Formats".
+
+A version 5 packet contains:
+
+  * A one-octet version number (5).
+
+  * A four-octet number denoting the time that the key was created.
+
+  * A one-octet number denoting the public-key algorithm of this
+    key.
+
+  * A four-octet scalar octet count for the following key material.
+
+  * A series of values comprising the key material.  This is
+    algorithm-specific and described in section XXXX.
+
 
 ### {5.5.3} Secret-Key Packet Formats
 
@@ -1903,7 +1929,10 @@ ### {5.5.3} Secret-Key Packet Formats
     indicates that the secret-key data is not encrypted.  255 or
     254 indicates that a string-to-key specifier is being given.
     Any other value is a symmetric-key encryption algorithm
-    identifier.
+    identifier.  A version 5 packet MUST NOT use the value 255.
+
+  * Only for a version 5 packet, a one-octet scalar octet count of the
+    next 3 optional fields.
 
   * [Optional] If string-to-key usage octet was 255 or 254, a one-
     octet symmetric encryption algorithm.
@@ -1916,6 +1945,9 @@ ### {5.5.3} Secret-Key Packet Formats
     octet not zero), an Initial Vector (IV) of the same length as
     the cipher's block size.
 
+  * Only for a version 5 packet, a four-octet scalar octet count for
+    the following key material.
+
   * Plain or encrypted series of values comprising the secret key
     material.  This is algorithm-specific and described in section
     XXXX.
@@ -1929,6 +1961,8 @@ ### {5.5.3} Secret-Key Packet Formats
     (if string-to-key usage octet is not zero).  Note that for all
     other values, a two-octet checksum is required.
 
+Note that the version 5 packet format adds two count values
+to help parsing packets with unknown S2K or public key algorithms.
 
 Secret MPI values can be encrypted using a passphrase.  If a string-
 to-key specifier is given, that describes the algorithm for converting
@@ -1948,8 +1982,8 @@ ### {5.5.3} Secret-Key Packet Formats
 at the beginning of each new MPI value, so that the CFB block boundary
 is aligned with the start of the MPI data.
 
-With V4 keys, a simpler method is used.  All secret MPI values are
-encrypted in CFB mode, including the MPI bitcount prefix.
+With V4 and V5 keys, a simpler method is used.  All secret MPI values
+are encrypted in CFB mode, including the MPI bitcount prefix.
 
 The two-octet checksum that follows the algorithm-specific portion is
 the algebraic sum, mod 65536, of the plaintext of all the algorithm-
@@ -3475,17 +3509,15 @@ ## {12.2} Key IDs and Fingerprints
 
     a.1) 0x99 (1 octet)
 
-    a.2) high-order length octet of (b)-(e) (1 octet)
-
-    a.3) low-order length octet of (b)-(e) (1 octet)
+    a.2) two-octet scalar octet count of (b)-(e)
 
-         b) version number = 4 (1 octet);
+    b) version number = 4 (1 octet);
 
-         c) timestamp of key creation (4 octets);
+    c) timestamp of key creation (4 octets);
 
-         d) algorithm (1 octet): 17 = DSA (example);
+    d) algorithm (1 octet): 17 = DSA (example);
 
-         e) Algorithm-specific fields.
+    e) Algorithm-specific fields.
 
     Algorithm-Specific Fields for DSA keys (example):
 
@@ -3497,18 +3529,49 @@ ## {12.2} Key IDs and Fingerprints
 
     e.4) MPI of DSA public-key value y (= g\*\*x mod p where x is secret).
 
+A V5 fingerprint is the 256-bit SHA-256 hash of the octet 0x99, followed
+by the four-octet packet length, followed by the entire Public-Key
+packet starting with the version field.  The Key ID is the high-order 64
+bits of the fingerprint.  Here are the fields of the hash material,
+with the example of a DSA key:
+
+    a.1) 0x9A (1 octet)
+
+    a.2) four-octet scalar octet count of (b)-(f)
+
+    b) version number = 5 (1 octet);
+
+    c) timestamp of key creation (4 octets);
+
+    d) algorithm (1 octet): 17 = DSA (example);
+
+    e) four-octet scalar octet count for the following key material;
+
+    f) algorithm-specific fields.
+
+    Algorithm-Specific Fields for DSA keys (example):
+
+    f.1) MPI of DSA prime p;
+
+    f.2) MPI of DSA group order q (q is a prime divisor of p-1);
+
+    f.3) MPI of DSA group generator g;
+
+    f.4) MPI of DSA public-key value y (= g\*\*x mod p where x is secret).
+
 Note that it is possible for there to be collisions of Key IDs -- two
 different keys with the same Key ID.  Note that there is a much
 smaller, but still non-zero, probability that two different keys have
 the same fingerprint.
 
-Also note that if V3 and V4 format keys share the same RSA key
+Also note that if V3, V4, and V5 format keys share the same RSA key
 material, they will have different Key IDs as well as different
 fingerprints.
 
 Finally, the Key ID and fingerprint of a subkey are calculated in the
-same way as for a primary key, including the 0x99 as the first octet
-(even though this is not a valid packet ID for a public subkey).
+same way as for a primary key, including the 0x99 (V3 and V4 key) or
+0x9A (V5 key) as the first octet (even though this is not a valid
+packet ID for a public subkey).
 
 # Elliptic Curve Cryptography
 
@@ -3648,7 +3711,8 @@ ## EC DH Algorithm (ECDH)
 
   - 20 octets representing a recipient encryption subkey or a master
     key fingerprint, identifying the key material that is needed for
-    the decryption.
+    the decryption.  For version 5 keys the fingerprint is right
+    truncated to 20 octets.
 
 The size of the KDF parameters sequence, defined above, is either 54
 for the NIST curve P-256 or 51 for the curves P-384 and P-521.
-- 
2.8.1

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: KellerFuchs <[email-masked]>
Date: Tue, 7 Mar 2017 23:06:05 +0000

>   <https://gitlab.com/openpgp-wg/rfc4880bis/commit/ba4f884c6d5483071d6adbc1e43978b60980440a>

Thanks a lot for doing this.

> [...]
> [...]

This is the first occurence of “right truncated”, as far as I can tell.

Since it's not entirely clear (at least to me) if this means keeping the 20
rightmost octets or dropping octets right of the 25th, not introducing it
is not ideal.

Furthermore, this hints at there being a left-truncation too, and having
both seems like a source of confusion. What about simply calling this “the
truncated 25-octets fingerprint” ?

Also, but I likely missed the relevant WG thread, why truncate the
fingerprint to 200 bits? (Not that this is likely an issue.)

Best,

  kf

---

From: Werner Koch <[email-masked]>
Date: Wed, 08 Mar 2017 08:02:54 +0100

> rightmost octets or dropping octets right of the 25th, not introducing it

What about this:

  -V4 keys use the untruncated 20 octet fingerprint; V5 keys use the
  -right truncated 25 octet fingerprint
  +V4 keys use the full 20 octet fingerprint; V5 keys use the
  +leftmost 25 octets of the fingerprint

   Note that the length N of the fingerprint for a version 4 key is 20
  -octets.  For a version 5 key N is 25 and the fingerprint is right
  -truncated to 25 octets.
  +octets.  For a version 5 key the leftmost 25 octets of the fingerprint
  +are used (N=25).

       key fingerprint, identifying the key material that is needed for
  -    the decryption.  For version 5 keys the fingerprint is right
  -    truncated to 20 octets.
  +    the decryption.  For version 5 keys the 20 leftmost octets of the
  +    fingerprint are used.

> fingerprint to 200 bits? (Not that this is likely an issue.)

That was a suggestion from the Berlin meeting.

Given that even for SHA-1 no pre-image attack is known, we get quite
some security margin by using 200 bits from SHA-256 over the 160 from
SHA-1.

When a truncated SHA-256 shows weaknesses we only need to replace two
signature subpackets but the fingerrprint won't change.

Due to the use of the 'Issuer Fingerpint' the signatures grow in size by
22 octets which is substantal for ECC signatures.  With the full V5
fingerprint this would increase to 25 octets (34 - 9 from the not used
'Issuer' subpacket).  By truncating the fingerprint we will only use 18
octets which is even a saving compared to V4 keys.

Shalom-Salam,

   Werner

---

From: Vincent Breitmoser <[email-masked]>
Date: Thu, 9 Mar 2017 13:41:10 +0100

> That was a suggestion from the Berlin meeting.

Can you (or someone else) give some more insight on the requirements
that were identified as a basis for this suggestion?

The SHA-3 contest reaffirmed that SHA-2 is doing just fine in terms of
cryptanalysis, so 160 bits truncated SHA-2 would be just fine even if we
consider strong collision resistance a requirement. But we had this
topic before, and from what I remember noone was able to come up with an
attack scenario where a collision would be useful in any way. Still the
idea now is to add another 40 bits on top?

 - V

---

From: KellerFuchs <[email-masked]>
Date: Thu, 9 Mar 2017 17:45:31 +0000

> > rightmost octets or dropping octets right of the 25th, not introducing it

This is very nice: basically as concise, and completely unambiguous
so it doesn't need a definition  :)

> octets which is even a saving compared to V4 keys.

Thanks a bunch for the explanation, this makes sense.

Best,

  kf

---

From: KellerFuchs <[email-masked]>
Date: Thu, 9 Mar 2017 18:47:45 +0000

> Thanks a bunch for the explanation, this makes sense.

PS: I still don't get what's the advantage of SHA-256 there over Blake2,
    given the current library support situation, security analysis and
    performance.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Mar 2017 11:11:03 -0800

>     given the current library support situation, security analysis and

I don't know anything about PGP library support, but my experience, at
least with SSL/TLS stacks, is that there is a lot more SHA-256 support than
support for {SHA-3, Blake2}
-Ekr

>
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

---

From: Jon Callas <[email-masked]>
Date: Thu, 09 Mar 2017 14:01:10 -0800

At the risk of sending this into a rathole, a viable alternative would be to use SHA512/t as a truncation function. It's got a well-defined way to deal with the issues of naive truncations, and you don't have to worry about defining how to truncate. If you want a 200 bit hash, you can just get one.

	Jon

---

From: Werner Koch <[email-masked]>
Date: Fri, 10 Mar 2017 11:08:27 +0100

On Thu,  9 Mar 2017 23:01, [email-masked] said:
> At the risk of sending this into a rathole, a viable alternative would
> be to use SHA512/t as a truncation function. It's got a well-defined

We had a discussion here on the merits of SHA-256 over SHA-512 with the
two arguments I already mentioned:

  - SHA-256 is much faster on smaller 32 bit systems
  - SHA-256 is anyway required to verify existing signatures.

An advantage of SHA-512 is that this would benefit an X25519-only based
implementation because that requires SHA-512 anyway.

Shalom-Salam,

   Werner

---

From: Jon Callas <[email-masked]>
Date: Fri, 10 Mar 2017 14:13:35 -0800

> On Mar 10, 2017, at 2:08 AM, Werner Koch <[email-masked]> wrote:
> 

This is a different suggestion, one about SHA512/t, which has an output length of 't' bits. It's a cute little hack that NIST put on top of SHA-512 to get a variable-output hash function.

I didn't bring in performance discussions because this is about fingerprints where it doesn't matter so much one way or the other. But since you did, you're right, that on a 32-bit system, SHA256 is faster. But on a 64-bit system, SHA-512 is faster, often like 1.5x faster.

But anyway, the suggestion is because if you're going to generate a 200-bit fingerprint, using a variable output hash function solves the problem of having to figure out how to truncate, as well as any issues in truncation.

	Jon

---

From: Werner Koch <[email-masked]>
Date: Tue, 14 Mar 2017 11:17:48 +0100

On Fri, 10 Mar 2017 23:13, [email-masked] said:

> This is a different suggestion, one about SHA512/t, which has an
> output length of 't' bits. It's a cute little hack that NIST put on
> top of SHA-512 to get a variable-output hash function.

Thanks for the pointer.  However this changes the semantics:

With SHA512/t we need to settle for a certain truncation because the
fingerprint depends on T.  The proposal defines a 32 byte fingerprint
and only uses truncated versions for the two signature subpackets and
the ECDH magic string.  Thus when a SHA-256 truncated to 200 bits shows
weaknesses, we only need to change the signature subpackets to use the
full 256 bits to address this weakness.  The fingerprint however will
not change and there won't be a need to create new keys.

You are right that computing a fingerprint should not be a performance
problem.  Thus we could also use SHA-512 as fingerprint algorithm and
truncate it to 200 bits.  I am actually slightly in favor of using
SHA-512 (but not SHA-512/t).

What do others think:

 - Use SHA-256 and truncated to 200 bits
 - Use SHA-512 and truncated to 200 bits
 - Anything else

Shalom-Salam,

   Werner

---

From: Werner Koch <[email-masked]>
Date: Thu, 16 Mar 2017 12:25:42 +0100

>  - Use SHA-512 and truncated to 200 bits

No opinions?

Shalom-Salam,

   Werner

---

From: Thijs van Dijk <[email-masked]>
Date: Thu, 16 Mar 2017 12:51:30 +0100

I'm in favour of truncating SHA-512 to 200 bits, though this is not a
strong preference.

-Thijs

(As a general principle, I like the idea of not exposing more than half of
a hash's internal state to the wild. A remnant of ye olden days where it
would've made length extension attacks that much more difficult.)

--
Thijs van Dijk

6A94 F9A2 DFE5 40E3 067E  C282 2AFE 9EFA 718B 6165

---

From: Peter Todd <[email-masked]>
Date: Thu, 16 Mar 2017 09:34:14 -0400

> >  - Use SHA-512 and truncated to 200 bits

Have you considered making fingerprints a non-hexidecimal encoding, such as
base32? They could be the same size, but with more bits.

Bitcoin Core has done a lot of research lately in creating a good base32
encoding with UI features like single-digit error detection and correction.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

---

From: Werner Koch <[email-masked]>
Date: Thu, 16 Mar 2017 14:43:48 +0100

> base32? They could be the same size, but with more bits.

The human readable fingerprint format is out of scope for the spec.

Salam-Shalom,

   Werner

---

From: Peter Todd <[email-masked]>
Date: Thu, 16 Mar 2017 10:03:46 -0400

> The human readable fingerprint format is out of scope for the spec.

Well, if that's the case, there's no reason to use less than a full 256 bits,
either SHA256 directly, or SHA512 truncated in the standard way.  How much of
that you truncate when displaying the fingerprint is a question for the human
readable spec, not the internal formatting spec.

---

From: Thijs van Dijk <[email-masked]>
Date: Thu, 16 Mar 2017 16:03:51 +0100

On 16 March 2017 at 15:03, Peter Todd <[email-masked]> wrote:

> either SHA256 directly, or SHA512 truncated in the standard way.

Sure there is. From earlier in this thread:

---

From: Derek Atkins <[email-masked]>
Date: Thu, 16 Mar 2017 11:25:36 -0400

>>  - Use SHA-512 and truncated to 200 bits

Considering these days I work with very small systems, I'm in favor of
SHA2-256 because in my environments it's much faster.  Even if SHA2-512
is faster on larger systems, the clock-wall time still gives SHA2-256
the advantage when you compare 256 vs 512 on a 16MHz 16-bit platform
versus a 32/64-bit 2GHz platform.

I.e., it doesn't bother me if SHA2-256 is a fraction of a millisecond
slower on a large system, but it's tens or hundreds of milliseconds
faster on the constrained device.

Thanks,

>    Werner

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Peter Todd <[email-masked]>
Date: Thu, 16 Mar 2017 13:35:15 -0400

> > octets which is even a saving compared to V4 keys.

Yes, I missed that message, sorry.

That said, I certainly don't find such small savings a good reason to use
"non-standard" crypto - in the grand scheme of things even on small devices
that's meaningless.

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Thu, 16 Mar 2017 17:25:38 +0000

(This is probably old info for some of you.)

From my analysis, the difference in speed between sha2-256 and sha2-512 is directly because of the use of 32-bit arithmetic vs 64-bit arithmetic. The algorithms are essentially identical, not counting the underlying constants. On machines where 64-bit arithmetic is faster than 32-bit arithmetic, sha2-512 will be faster than sha2-256. On machines where 32-bit arithmetic is faster than 64-bit arithmetic, sha2-256 will be faster than sha2-512. On 8-bit or 16-bit machines, you’re going to be emulating either 32-bit arithmetic or emulating 64-bit arithmetic; usually the 32-bit arithmetic will be faster.  :-)

On another note, for Werner Koch: are you talking about truncating the value from sha2-512(x) down to 200 bits, or using the FIPS 180-4 truncated sha2-512/t(x,t) algorithm? There is a definite difference between the two. FIPS 180-4 defines differing underlying vectors for different lengths of t (the truncation value).

Note that FIPS 180-4 defines the function for all positive values of t <512, but only >approves< its use for 224 and 256. This might be an argument for use 224 instead of 200.

- Tony Hansen

On 3/16/17, 11:25 AM, "openpgp on behalf of Derek Atkins" <[email-masked] on behalf of [email-masked]> wrote:

    

    Thanks,

    -derek

    _______________________________________________
    openpgp mailing list
    [email-masked]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_openpgp&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=vM6RhLQF242nU4VMyV4DjMhHsEUQeou96eZFYalUF6A&s=ksU0kzU9qTx2kcTtA-JsnQ1IE9CA8gsM-1iYvKPDFCU&e=

---

From: Werner Koch <[email-masked]>
Date: Thu, 16 Mar 2017 20:46:57 +0100

On Thu, 16 Mar 2017 18:25, [email-masked] said:

> On another note, for Werner Koch: are you talking about truncating the
> value from sha2-512(x) down to 200 bits, or using the FIPS 180-4
> truncated sha2-512/t(x,t) algorithm? There is a definite difference

I am talking about simple truncation (leftmost 200 bits (25 octets)) of
SHA-256/512 similar to what Git does.  I explained the reason in my
reply to Jon's suggestion for SHA-512/t: This will make it easy to get
rid of the truncation iff need arises - without defining a new key
format.  That is the full fingerprint will be the same and searches for
the truncated or full fingerprint will still return the same key.

Salam-Shalom,

   Werner

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 16 Mar 2017 23:21:50 +0000

Derek Atkins <[email-masked]> writes:

>I.e., it doesn't bother me if SHA2-256 is a fraction of a millisecond slower
>on a large system, but it's tens or hundreds of milliseconds faster on the
>constrained device.

+1.

Also, like AES' 256-bit option, I get the feeling that SHA-512 exists purely
for people who want their algorithms to go to 11.  It doesn't solve any
obvious problem that SHA-256 doesn't already address, while leading to serious
practical issues when you're required to attach e.g. a 64-byte MAC to 5 bytes
of SSL payload.

Peter.

---

From: "brian m. carlson" <[email-masked]>
Date: Fri, 17 Mar 2017 01:17:57 +0000

> >  - Use SHA-512 and truncated to 200 bits

If you want a truncated format you can extend later, why not use
SHAKE128 or SHAKE256?  Then you don't have to implement a non-standard
truncation.  If we implement something like Curve448, we're probably
going to need SHAKE256 anyway.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

---

From: Werner Koch <[email-masked]>
Date: Fri, 17 Mar 2017 09:36:44 +0100

> SHAKE128 or SHAKE256?  Then you don't have to implement a non-standard

SHAKE is not part of OpenPGP yet and I doubt that this will be a
mandatory algorithm in 4880bis.  SHA-256 is de-facto a mandatory
algorithm right now and available in all OpenPGP implementations.

We need to provide a smooth upgrade path for implementations and not
require them to throw new algorithms in.

Salam-Shalom,

   Werner

---

From: Jon Callas <[email-masked]>
Date: Fri, 17 Mar 2017 11:05:17 -0700

My preference is to use SHA-512. My rationale is:

* Fingerprints of keys don't have to be computed continuously. They can be computed ones and the result cached for a reasonably long period of time. For every argument about speed on small machines, there's an equal and opposite counter-argument about speed on large machines. I've pulled my hands back several times from saying more. I won't unless provoked. I think the better argument is that speed of computing a fingerprint doesn't matter.

* If we use SHA-512, we extend the length of time before we have to have this argument again.

	Jon

---

From: Derek Atkins <[email-masked]>
Date: Mon, 20 Mar 2017 11:34:41 -0400

Tony,

"HANSEN, TONY L" <[email-masked]> writes:

> From my analysis, the difference in speed between sha2-256 and
> sha2-512 is directly because of the use of 32-bit arithmetic vs 64-bit
> arithmetic. The algorithms are essentially identical, not counting the
> underlying constants. On machines where 64-bit arithmetic is faster
> than 32-bit arithmetic, sha2-512 will be faster than sha2-256. On
> machines where 32-bit arithmetic is faster than 64-bit arithmetic,
> sha2-256 will be faster than sha2-512.

That's nice.

I'm working on systems which are 16-bit or even 8-bit wide, with clock
speeds in the single or low-double-digit MegaHertz.  Yes, I'm running
(parts of) OpenPGP in these environments.  This is why I'm arguing for
SHA-256.  Because sure, if you're running at 2.4GHz and you need to take
an extra million cycles you'll never notice, but if you're running at
16MHz ... OUCH.

>   On 8-bit or 16-bit machines,
> you’re going to be emulating either 32-bit arithmetic or emulating
> 64-bit arithmetic; usually the 32-bit arithmetic will be faster.  :-)

Exactly.   So what's the actual wall-clock difference of 256 vs 512 on
an Intel 64 running at 2.2GHz?  Well, just for kicks I decided to run an
openssl speed test on my laptop (Intel(R) Core(TM) i7-4800MQ CPU @
2.70GHz) and this is what I get:

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           79196.40k   177603.09k   319138.68k   406628.35k   438559.68k
sha512           51763.29k   206704.67k   366123.95k   555307.69k   647932.40k

As you can see, sha256 is faster on small inputs, but by 64 bytes of
input sha512 gets to be a tad faster.  For what we're talking about here
we're probably between the 64 and 256 byte marks, where they look pretty
equal on this nice, cushy 2.7GHz 64-bit i7 CPU (177-319 vs 206-366
MB/sec, or kB/ms).  So basically, assuming 100B of data to be hashed,
we're talking about 349-403us a 15% speed difference (only 54us
difference). I don't think anyone would notice an extra 54us.

Alas, I don't have an MSP430 at my fingertips to run a similar test, but
I suspect the difference is significantly more.  For one thing the clock
speed is only around 16-24MHz, not 2.7GHz.  To make the math easy, let's
call it 27MHz.  So all else being equal (which it isn't, being a 16-bit
platform and not a 64-bit platform), accounting *JUST* for the clock
speed we're talking a 100x speed difference, or 5.4ms.

But of course all else ISN'T the same, so we probably are talking a good
20-50ms speed difference, which *IS* noticible.  I'll see if I can get
some actual numbers on the MSP430, but I'm traveling the next couple
days and don't have my dev board with me so it might not happen quickly.
But even if we agree that the difference is only 25ms, I'd rather save
that 25ms on the MSP430 at the expense of 54us extra on a 3-year-old
Intel laptop.

Sure, if everyone is running Intel 64 I wouldn't question the choice.
If the difference between was under a millisecond I wouldn't care.  But
that's not the world I'm living in, but it's the world I'd like to
deploy (parts) of OpenPGP.  I'd love to have a 32-bit system running in
the GHz at my disposal.

-derek