Subject: Re: [openpgp] New fingerprint: to v5 or not to v5

From: Watson Ladd <[email-masked]>
Date: Thu, 1 Oct 2015 18:39:11 -0400

On Wed, Sep 30, 2015 at 2:00 AM, Werner Koch <[email-masked]> wrote:
> On Tue, 29 Sep 2015 20:40, [email-masked] said:
>
>> v4 key and wrap it in a v5 packet, thereby producing a "new key" that's
>> actually the "same key".  So claiming that key material can only be used
>> as *either* v4 or v5 wouldn't quite be correct.
>
> FWIW: I was thinking about this but that is not limited to OpenPGP.  I
> can use the same key material for an OpenPGP key, an X.509 key, and an
> SSH key.  This is actually sometimes useful if you have a single key on
> a smartcard.

Have you conducted a proper cross-protocol analysis of what data each
key type is used to sign showing that this interaction doesn't lead to
bad things happening?

>
>
> Salam-Shalom,
>
>    Werner
>
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 3 Oct 2015 21:50:16 -0400

> key type is used to sign showing that this interaction doesn't lead to

Yes, hence the reason for my UDF design which salts the hash with the mime
content type of the data being hashed. Thus one fingerprint format can be
used for a S/MIME key or an OpenPGP key or an SSH key.

---

From: Tom Ritter <[email-masked]>
Date: Sun, 4 Oct 2015 12:27:53 -0500

On 30 September 2015 at 01:18, Werner Koch <[email-masked]> wrote:
> On Mon, 21 Sep 2015 11:13, [email-masked] said:
>
>> Regarding which hash to use, SHA-256 is probably the simplest choice
>> From a practicallity and consensus point of view.  Are there any strong
>> reasons to favor something else?

I have a small preference to see the fingerprint algorithm match what
we believe the most popular signature (hash) algorithm will be. I've
been working with a number of embedded folks and code size can often
be a big concern. More Algorithms, More Code.

-tom

---

From: Werner Koch <[email-masked]>
Date: Sun, 04 Oct 2015 20:22:06 +0200

> used for a S/MIME key or an OpenPGP key or an SSH key.

See rfc-4880, 12.2 (Key IDs and fingerprints)

  Here are the fields of the hash material, with the example of a DSA
  key:

   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)
     b) version number = 4 (1 octet);
     c) timestamp of key creation (4 octets);
     d) algorithm (1 octet): 17 = DSA (example);
     e) Algorithm-specific fields.

   Algorithm-Specific Fields for DSA keys (example):
   e.1) MPI of DSA prime p;
   e.2) MPI of DSA group order q (q is a prime divisor of p-1);
   e.3) MPI of DSA group generator g;
   e.4) MPI of DSA public-key value y (= g**x mod p where x is secret).

also the MPI format is different from X.509 and from SSH.

Thus we already "salt" the fingerprints with version numbers and a
timestamp and get different fingerprints for these 3 protocols and most
likely for all protocols even for the same key material.  For a v5 key
the fingerprint will also be different due to a.3b).

Salam-Shalom,

   Werner

---

From: "Mark D. Baushke" <[email-masked]>
Date: Sun, 4 Oct 2015 20:43:56 -0700

> On Sun,  4 Oct 2015 03:50, [email-masked] said:
...
> See rfc-4880, 12.2 (Key IDs and fingerprints)
...
>     c) timestamp of key creation (4 octets);

This reminds me. I suspect we want to move to be explicit that the
timestamp is unsigned during RFC 4880bis, or we want to allocate
more bits and make it a 64-bit integer (8 octets).

The currnet POSIX-compliant epoch time_t starting at midnight January 1,
1970 using a signed 32-bit integer (4 octets) runs into trouble at 0x80000000 
03:14:08 UTC on 19 January 2038 which might also be read as
20:45:52 UTC on 13 December 1901 (-2147483648).

	-- Mark

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 5 Oct 2015 10:27:02 +0000

Werner Koch <[email-masked]> writes:

>Thus we already "salt" the fingerprints with version numbers and a timestamp
>and get different fingerprints for these 3 protocols and most likely for all
>protocols even for the same key material.  For a v5 key the fingerprint will
>also be different due to a.3b).

... which is a major pain because the value used to ID the key changes with
any tiny change in the metadata surrounding it, so you can no longer identify
the key that was used to sign something.  The timestamp is the real killer,
since non-PGP key formats don't record this and there's no explicit storage of
the keyID (it's implicitly calculated from data that isn't available in non-
PGP storage), you can no longer track down which key did what.  I've got
around it by always recording a creation time of zero for keys (so you just
hash four bytes of zeroes), but this only works for keys created in my code
that knows about this convention.

The whole PGP key format as it currently stands is rather a mess.  There's no
single entry for a key but a connected series of packets of arbitrary number
where you have to perform arbitrary amounts of lookahead to see where they
end, then a second pass to parse the packets, and then more iterative passes
to resolve all the bits and pieces in the packets.  Since the keyID is
generated implicitly from the packets, you have to do this each time you
search a keyring.  There are all sorts of attributes, often only vaguely
defined, that can be attached at any point where a signature can be found. The
descriptions contain gems like:

   This is a flag in a User ID's self-signature that states whether this User
   ID is the main User ID for this key [...] If more than one User ID in a key
   is marked as primary, the implementation may resolve the ambiguity in any
   way it sees fit, [...]

I have no idea what would happen if you created entries like ones with
multiple subkeys or conflicting attributes in different locations, but I'd
imagine the behaviour of implementations would be pretty much a coin-toss, and
the spec doesn't help.  I've got around this in my code by assuming a
canonical "one main key, one subkey, some userIDs", with anything outside this
ignored.  This leads to predictable, deterministic behaviour and (hopefully) a
lack of surprises, like the one I'm currently dealing with where a particular
implementation wants to see a certain arrangement of packets and attributes
and I'm still not sure what they are.

If the keyring format is redefined for the PGPng, I'd really like to see the
format be made more usable, something like (for each entry):

header (type + length )
  {
  ID information (explicitly stored, not implicitly generated);
  primary key;
  [ optional subkey ];
  user IDs;
  certifications (signatures);
  }

To find a key:

  foreach entry
    {
    read length;
    check IDs for a match;
    if( match )
      break;
    skip length bytes;
    }

With the IDs explicitly stored, you no longer need some complex hash-based
value to identify the key, you can use any probabilistically-unique value.

Peter.

---

From: Werner Koch <[email-masked]>
Date: Mon, 05 Oct 2015 12:43:11 +0200

> more bits and make it a 64-bit integer (8 octets).

I was thinking about this but:

 3.1.  Scalar Numbers

   Scalar numbers are unsigned and are always stored in big-endian
   format.  Using n[k] to refer to the kth octet being interpreted, the
   value of a two-octet scalar is ((n[0] << 8) + n[1]).  The value of a
   four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) +
   n[3]).

Thus it is an implementation problem for 32 bit systems which still have
not switched from to a 64 bit time_t or fixed their implementation to
work with dates after 2038 (which is not a problem because only
(time_t)(-1) has a special meaning).

I doubt that we need to care about the year 2106 already in a v5 format.

> 1970 using a signed 32-bit integer (4 octets) runs into trouble at 0x80000000 

POSIX 2001 says in Base Definitions, line 13001:

  - time_t and clock_t shall be integer or real-floating types.

it is not specified whether signed or unsigned and thus both are
allowed.

Shalom-Salam,

   Werner

---

From: Werner Koch <[email-masked]>
Date: Mon, 05 Oct 2015 13:33:14 +0200

> since non-PGP key formats don't record this and there's no explicit storage of

The only variable thing is the timestamp with the creation date.
Everything else is fixed and depends only on the key material.

I very well know the pain with the creation date which for example
forces the OpenPGP card to have a creation date DO in addition to the
fingerprint and in some other cases you need to guess/try the creation
date to make a fingerprint form the raw key material.

Is your request to leave the timestamp out of a v5 fingerprint
computation?

That would make some things easier but raises the issue that the owner
of the key can change the creation date and only the then broken key
signatures and the history of self-signatures would reflect this.

> If the keyring format is redefined for the PGPng, I'd really like to see the

That is out of scope for the current work.

Salam-Shalom,

   Werner

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 5 Oct 2015 11:44:39 +0000

Werner Koch <[email-masked]> writes:

>Is your request to leave the timestamp out of a v5 fingerprint computation?

Either leave it out or, much better, use an explicit ID stored with the key
rather than one that's implicitly calculated from various bits and pieces
surrounding the key.  That's how PKCS #15 and (ugh) PKCS #12 do it, it makes
key lookup much less of a pain and avoids the current lost-key problem where
you can't match up a key to a signature even though it's present and
available.

>That is out of scope for the current work.

I can't see anything in the charter that would exclude it, it says the work
items "include, but are not limited to ...", and specifically allows for work
that won't unduly delay things and that has support from the WG.

Peter.

---

From: ianG <[email-masked]>
Date: Mon, 5 Oct 2015 10:16:23 -0400

> Is your request to leave the timestamp out of a v5 fingerprint

Makes sense to me.

Or, as it is just a calculation, the 4 octets MUST be set to 0.

> signatures and the history of self-signatures would reflect this.

I don't understand why that is an issue for the fingerprint?

> That is out of scope for the current work.

:)  Maybe spun off into a separate draft?

iang

---

From: ianG <[email-masked]>
Date: Mon, 5 Oct 2015 10:01:52 -0400

On 4/10/2015 23:43 pm, Mark D. Baushke wrote:
> timestamp is unsigned during RFC 4880bis,

Agreed - redefined to be unsigned.

It's timely (pun intended).

iang

---

From: Werner Koch <[email-masked]>
Date: Tue, 06 Oct 2015 08:50:04 +0200

> I don't understand why that is an issue for the fingerprint?

Because that changes the behaviour in the error cases.

Salam-Shalom,

   Werner

---

From: Werner Koch <[email-masked]>
Date: Tue, 06 Oct 2015 10:01:08 +0200

> rather than one that's implicitly calculated from various bits and pieces

That explicit ID sounds pretty much like a issuer+serialno or one of the
other X.509 methods to identify a key.  It is not a fingerprint as we
know it and it can't be used as a secure identification of the key.

> you can't match up a key to a signature even though it's present and

Lost key?  Do you mean missing Issuer subpacket (5.2.3.5) or one
pointing two keys with duplicated long keyids?  I have never seen the
former and in any case I would consider this a corrupted message.  To
fix the latter we will certainly define the use of a fingerprint.

> that won't unduly delay things and that has support from the WG.

Changing the entire packet structure is not an easy thing and definitely
would delay the listed goals.

Salam-Shalom,

   Werner

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 6 Oct 2015 11:03:30 +0200

> >> Regarding which hash to use, SHA-256 is probably the simplest
> >> choice From a practicallity and consensus point of view.  Are
> >> there any strong reasons to favor something else?
> 

My perception is that the most popular signature hash algorithms right
now are SHA-256 and SHA-512.  While SHA-256 and SHA-512 have somewhat
different characteristics on different platforms, I believe we are
approaching the limit of where a lot of additional comparisons are
worth the time and effort compared to just pick one of them.  I'm fine
with SHA-256 for the reasons that Werner presented.  Does someone
else want to promote another option?  Can we get closure on this?

/Simon

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 7 Oct 2015 14:02:17 +0000

Werner Koch <[email-masked]> writes:

>other X.509 methods to identify a key.  It is not a fingerprint as we know it
>and it can't be used as a secure identification of the key.

It works quite well as a unique identifier for a key.  The problem here is
that PGP makes the same mistake that's made in things like credit cards and
SSNs, where you've got a magic value that's supposed to be both a unique
identifier (public) and an authentication/authorisation value (private).

X.509 handles this by having two distinct things, a unique identifier
(subjectKeyIdentifier) to identify a key, and a fingerprint (hash of the cert)
to verify its integrity or whatever it is you want to do with it.

PGP in contrast confuses the two, so you have a supposedly unique identifier
that hashes in a mutable value (the time) but then doesn't hash in other
important information like the user ID associated with the key.  So it doesn't
work very well either as an identifier or as an integrity-check value.

The fix would be to have two distinct values, a unique identifier (64 or 128
bits of whatever) to uniquely identify a key, and then a fingerprint that
covers the key, subkey(s), user ID(s), attributes, and whatnot, to check that
you've got what you were expecting to get.

>Lost key?  

The key is present somewhere on the keyring but the date has changed, so you
can't locate it by key ID any more because the date hashed into the other bits
and pieces changes the key ID.

Peter.

---

From: Werner Koch <[email-masked]>
Date: Wed, 07 Oct 2015 21:33:34 +0200

> (subjectKeyIdentifier) to identify a key, and a fingerprint (hash of the cert)

Which is not defined by any standard.

> important information like the user ID associated with the key.  So it doesn't

As you surely know PGP can't add the user ID because the user id is
attached to the key so that you can add or remove user ids.

> you've got what you were expecting to get.

It will only take a few days until the first wags create multiple
different keys with the same identifier to confuse software.  Think of
the collisions in 64 bit key ids which will sooner or later lead to
problems in current OpenPGP.

Let's call your proposed system UnDER.509.

> and pieces changes the key ID.

I call this corrupt data.  The self-signature would not verify and thus
the key is unusable.  Time to remember where you stored the backup.

Shalom-Salam,

   Werner

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 8 Oct 2015 15:16:50 +0000

>Which is not defined by any standard.

You don't need a standard to tell you that a SHA-1 hash of a certificate is
obtained by taking a certificate and hashing it with SHA-1.  Pretty much
everything has supported this for years, typically under the name of
certificate fingerprint.

>It will only take a few days until the first wags create multiple different
>keys with the same identifier to confuse software.

X.509 has been using this mechanism for about twenty years without any
problems.  Sure, someone could do that, but what would they gain by it?  The
same wags could create a key with a colliding email address attached to it,
and they've been able to do that for twenty years as well but the world hasn't
ended because of it.

>I call this corrupt data.  The self-signature would not verify and thus the
>key is unusable.  Time to remember where you stored the backup.

It's not corrupted, someone just updated their key info, the signatures on the
new key data are all valid.  The fact that the exact same key that was used
earlier, with the exact same name/email address attached to it, now has a
totally different identifier associated with it, is a problem with how PGP
identifiers are handled.  No data corruption has taken place.

Peter.

---

From: Werner Koch <[email-masked]>
Date: Thu, 08 Oct 2015 17:42:01 +0200

> problems.  Sure, someone could do that, but what would they gain by it?  The

YMMV: I have seen serial number re-use for different keys done by
official CAs more than once.

> It's not corrupted, someone just updated their key info, the signatures on the

What do you mean by "key info".

> identifiers are handled.  No data corruption has taken place.

You mean the binding signatures verify okay but the key is different?
If that is the case you found a bug in the software.  You can't change
the creation date, the key material, the user id or the hashed signature
subpackets without invalidating the corresponding self-signature.

Shalom-Salam,

   Werner

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 8 Oct 2015 15:52:09 +0000

Werner Koch <[email-masked]> writes:

>You mean the binding signatures verify okay but the key is different? If that
>is the case you found a bug in the software.  You can't change the creation
>date, the key material, the user id or the hashed signature subpackets
>without invalidating the corresponding self-signature.

There's no bug in the software, someone took the key (that's the key data, not
a complete copy of the original keyring packets with their signatures) and
wrote it out to a new keyring with a new date.  Same key, same userID,
different date (because it was written at a different time than before), new
signatures covering everything.  There are no bugs and no corruption, but the
implicitly-calculated key ID has changed because the datestamp has changed.

Peter.

---

From: ianG <[email-masked]>
Date: Thu, 8 Oct 2015 23:48:14 +0100

On 6/10/2015 10:03 am, Simon Josefsson wrote:
> now are SHA-256 and SHA-512.

Err... A few minor quibbles here about the notions of cryptographic 
democracy:

1.  Popularity?  Why is that interesting?  Surely we can do a bit better 
than democracy or fashion or votes on cat pictures?

Engineering or planning, anyone?

2.  The reason SHA-256 is the most popular these days is that, in the 
wake of the 2004 Shandong hashquake, we've made a stunning amount of 
progress in upgrading.  We've almost decided against SHA1 in 
certificates.  We're almost serious about it.  And now that freestart 
collisions are chewing it down to its last 4 bits, we might actually ... 
do it.

(Which is to say, popularity got us to a situation where *11* years 
after the shots were fired, and 15 years after the new version was 
delivered, we're still using lots and lots of SHA1.  We want to improve 
that with 15 year old tech?)

3.  It's certainly a stunning indictment on algorithmic agility that 
SHA1 is still an issue, which is another process by which popularity 
makes its objective mark.

> While SHA-256 and SHA-512 have somewhat

---

From: [email-masked]
Date: Fri, 09 Oct 2015 10:38:27 -0400

On 10/8/2015 at 6:45 PM, "ianG"  wrote:
Engineering or planning, anyone?

.....

(Which is to say, popularity got us to a situation where *11* years 
after the shots were fired, and 15 years after the new version was 
delivered, we're still using lots and lots of SHA1.  We want to
improve 
that with 15 year old tech?)

=====

So if it's a new key version V5, may be it would be reasonable to go
with a the new hash standard, SHA 3 (Keccak)

http://www.nist.gov/manuscript-publication-search.cfm?pub_id=919061
vedaal

---

From: Steve Pointer <[email-masked]>
Date: Fri, 09 Oct 2015 16:48:19 +0100

> So if it's a new key version V5, may be it would be reasonable to go with a the new hash standard, SHA 3 (Keccak)

Surprised that nobody has mentioned Suite B:

https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml

Last updated a couple of months ago to advise:

"Use SHA-384 to protect up to TOP SECRET."

http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf 

--
Steve P

---

From: Alessandro Barenghi <[email-masked]>
Date: Fri, 9 Oct 2015 16:47:03 +0000

On 10/08/2015 10:48 PM, ianG wrote:

> collisions are chewing it down to its last 4 bits, 

Actually, they finished chewing
https://sites.google.com/site/itstheshappening/

(still only a freestart collision, but full 80 rounds)

> we might actually ... do it.

Yep, and IMHO picking a hash function with a different inner structure
from SHA-1, and designed to address the issue coming with it, such as
SHA-3 may quite be a good idea.
After all, ~89% of the signatures currently present on the sks keyserver
network are made over a SHA-1 hash, and it may take a while to update
them all.

Cheers

Alessandro

---

From: "Robert J. Hansen" <[email-masked]>
Date: Fri, 9 Oct 2015 13:14:03 -0400

> SHA-3 may quite be a good idea.

I feel like a churl for observing this, but the history of
Merkle-Damgård hashes is really not very good.  MD4, MD5, SHA-0, SHA-1,
RIPEMD, and probably RIPEMD-160 and/or RIPEMD-128.

Some of this is because these are popular hash functions and as a result
have received the most cryptanalysis.  But part of me wonders if now
would not be an excellent time to introduce a non-Merkle-Damgård hash to
OpenPGP, in the hopes that maybe it will fare better.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 09 Oct 2015 14:44:46 -0400

> Or, as it is just a calculation, the 4 octets MUST be set to 0.

<no hats>

I would agree that leaving the key creation time out of the fingerprint
calculation makes it easier to associate the mathematical object of raw
key material with an explicit key ID.

For X.509, we do have certificate fingerprints, but they turn out to not
be particularly useful.  The main place where X.509 fingerprints have
come in handy in protocols is in HPKP, where the subjectPublicKeyInfo
material is what is fingerprinted, not the certificate itself.

>> signatures and the history of self-signatures would reflect this.

if the fingerprint calculation doesn't include the key creation time,
we would also need to decide whether key creation time should be
included in the material digested for other OpenPGP certifications.

in that case, i see three options:

 a) don't include any key creation time at all; signatures themselves
    have a creation time, which is sufficient.

 b) include key creation time in the material certified only for
    self-sigs (certifications issued by the key itself).  Do not include
    any key creation time in the material certified by third-parties.

 c) Include creation time of the certified key in the material certified
    for all certifications -- first-party or third-party.

I'm tempted by the simplicity of (a), to be honest.

(b) sounds doable, but i don't know how useful it is to have assertions
from the key of when the key was created, or what to do with situations
where some self-sigs assert a different key creation time than others.
Should we reject or ignore some of them?  if so, which ones?

(c) sounds like trouble -- you'll get self-signed assertions of key
creation time that don't match third-party assertions of key creation
time.  What does that mean?  how should it be represented to the user?
I think this is the issue that Werner was hinting at.

what are the downsides of (a)?  What are the advantages of having a key
creation time at all?  Is it simply that it provides a universally-known
temporal boundary when to accept signatures made by that key?

        --dkg

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 10 Oct 2015 02:11:42 +0000

Daniel Kahn Gillmor <[email-masked]> write:

>For X.509, we do have certificate fingerprints, but they turn out to not be
>particularly useful.

Actually they're very useful if you're doing proper checking in your PKI (so
not relying on commercial CAs or any of the X.500/X.509 folderol that doesn't
work), you either fingerprint the cert(s) you expect to see (e.g. for securing
a web service for a mobile app) or the CA cert that you rely on to issue certs
you can rely on. You can also use them for cute things like self-certifying
URLs, the first part of the FQDN is a hash of the cert at that location.

Peter.

---

From: Jonathan McDowell <[email-masked]>
Date: Sat, 10 Oct 2015 11:35:49 +0100

> temporal boundary when to accept signatures made by that key?

I've certainly used key creation time as a separate piece of information
to "most recent self-signature". The latter indicates how recently the
key can be seen as still in use / maintained, but the former gives an
idea of how long it's been around and can help when making a decision
about which of multiple keys to use for an individual. I think having
that in the self-sig would work ok (i.e. option b). In general is the
most recent self-sig not the one that should be trusted, with perhaps a
warning if any of the previous ones have a different creation time
listed?

J.

-- 
Friends are God's apology for relations.

---

From: Nicholas Cole <[email-masked]>
Date: Sun, 11 Oct 2015 10:02:38 +0100

> warning if any of the previous ones have a different creation time

For what it is worth, I think that a secure creation time is probably
useful to some, and should be preserved if possible. If it can be included
in the hashed material for the key (as it currently is) in a way that does
not help people to forge keys, then I think it should be -- including it
only as a piece of signed data is going to allow key owners to manipulate
it.

---

From: Vincent Breitmoser <[email-masked]>
Date: Mon, 12 Oct 2015 14:06:27 +0200

The creation date in the fingerprint is used for two purposes I can
think of:

Firstly, it is commonly used by users to pick a key when a keyserver
search returns more than one result, which is made possible without
processing the full key by integrity protecting the creation date in the
fingerprint.  It is questionable whether this behavior should be
encouraged, but if there is no attacker this is often a reasonable
guess.  If there is an attacker, you are doomed no matter what you do
with an unauthenticated key.

Secondly, implementations use it as a boundary for signature validity.
I don't think this behavior is actually specified, so this is mostly
just guesswork in the trust model?

Including the key material as the only dynamic part of the fingerprint
is the most basic decision.  So the question becomes, do we have a good
reason to include anything more?  For the creation date in particular,
are the above two properties desirable and worth it?

Just for brainstorming, the other extreme would be allowing arbitrary
properties (e.g. signature subpackets) to be included in the
fingerprint, allowing an implementation to have properties which can
never change throughout the lifetime of a key, and which cannot be
suppressed by an attacker unlike irrecovable signature packets.

 - V

---

From: "Daniel A. Nagy" <[email-masked]>
Date: Mon, 12 Oct 2015 14:46:09 +0200

Hello,

Now that SHA1 is on the brink of being broken, I believe that all
Merkle–Damgård hashes should be avoided in new designs. Keccak (SHA-3)
is just better in so many ways.

Daniel

---

From: Werner Koch <[email-masked]>
Date: Mon, 12 Oct 2015 16:07:59 +0200

> The creation date in the fingerprint is used for two purposes I can

and this one:

Thirdly, to figure out a suitable subkey for encryption.  For this case
I see no security problem to put the creation date into a key-binding
signature.  IT needs quite some code chnages though.

> reason to include anything more?  For the creation date in particular,

I don't think so.  v3 keys didn't include the timestamp in the
fingerprint but had other problems.  Maybe this was just an
over-cautiousness from the PGP-5 architects.  Jon: Do you remember?

Assuming we leave the timestamp out of the fingerprint but still sign it
with the self- and key-binding signatures, how does it change the attack
model:

For a key without any third party key-signatures, the holder of the key
can change the creation date arbitrarily while keeping the same
fingerprint.  The immediate problem will be that keyservers and other
code may choke on the timestamp conflict because they may assume two
keys with the same fingerprint are identical.  Even today keys may not
be identical because there are different ways to encode the packet
length.  I doubt that this is or should be a problem which cannot be
fixed while adding v5 format.  The holder of the key can change the
expiration time of the key by adjusting the creation timestamp.  He is
also able to do this today by issuing a new self-signature.

If the key has a third party key-signature any change of the creation
time can be detected.  If key-signatures are part of the trust model
such a change will be detected.

I conclude that leaving out the timestamp from the fingerprint
computation is only a problem for "self-signed" keys where the trust
model is based solely on the fingerprint, and relies on the creation
date.  Not something I would worry about.

> fingerprint, allowing an implementation to have properties which can

We had a similar discussion already related to a fixed expiration time.
Although this hard-wired expiration time was not considered to be part
of the fingerprint, no valid use-case for this irrevocable signature
attribute was shown.

Salam-Shalom,

   Werner

---

From: Werner Koch <[email-masked]>
Date: Mon, 12 Oct 2015 16:41:37 +0200

> wrote it out to a new keyring with a new date.  Same key, same userID,

Which is a freature in my book.  People have done this for X.509 keys a
lot (although I heard that Mozilla now complains about using a new X.509
certificate with key material known from another certificate).

Shalom-Salam,

   Werner

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 13 Oct 2015 04:19:26 +0000

Werner Koch <[email-masked]> writes:

>People have done this for X.509 keys a lot (although I heard that Mozilla now
>complains about using a new X.509 certificate with key material known from
>another certificate).

The practice is unfortunately far too common in the X.509 world, where the
same key is re-certified year in, year out.  The end result is a worst-of-
both-worlds system where you're forced to pay a CA every year to make the
browser warnings go away, but don't get the benefit of changing your key to
limit the damage due to a compromise.  It's more PKI security theatre I
guess...

Peter.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 13 Oct 2015 06:59:28 -0400

> limit the damage due to a compromise.  It's more PKI security theatre I

X509 keys are authentication keys. You cannot go back and authenticate
things that failed after compromise.

---

From: Werner Koch <[email-masked]>
Date: Tue, 13 Oct 2015 13:33:23 +0200

> X509 keys are authentication keys. You cannot go back and authenticate

Of course they are also used for encryption.  That is specified by the
key-usage (which commonly allows signing and encryption with the same
key).  Recall that X.509 keys are not only used for TLS but also for
CMS.

Shalom-Salam,

   Werner

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 23 Oct 2015 14:00:56 -0400

> is just better in so many ways.

The consensus among folk who followed the SHA-3 competition more
closely that I did was that they came to understand a lot more about
SHA-2 and were much more confident about it as a result.

The strong consensus is that every application requiring a digest
should require either SHA-2 or SHA-3 and strongly recommend BOTH.

SHA-3 is a newer construction and has been chosen so that it is highly
unlikely that a single attack would defeat both. But it is not
considered 'more secure'. It is different but that only gives you an
advantage if you use both so that you can make use of the diversity.

We stopped using MD5 very quickly. Most people had dropped it before
the attack was widely known. That was possible because SSL 2.0 had
required the use of MD5 and SHA-1 to construct the MAC. So the
transition was painless. It took the platform providers much longer to
support SHA2 and when they did they refused to support any mechanism
that would make it easy to manage the transition.

Due to the way OpenPGP works, it is not possible to have a recommended
algorithm for fingerprints. Every client has to be able to process any
recommended algorithm, so recommended means 'mandatory to accept'. But
there should definitely be two algorithms to choose from.

That is why I use the first octet in UDF to serve as an algorithm
flag. It is precisely so that we can adapt if the need should arise.
We can argue as to whether we need 8 bits or could survive with 5 or
even one. But if you want to do the job properly you need to have an
identifier.

The other part of UDF is constructed so that it is possible to use the
same support infrastructure for both OpenPGP fingerprints and SSH
fingerprints without any risk of unfortunate interactions.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 23 Oct 2015 16:16:10 -0400

> there should definitely be two algorithms to choose from.

In earlier discussions, i think people have made pretty convincing
arguments that "two algorithms to choose from" is not a useful
arrangement for OpenPGP fingerprints.

In particular, fingerprints are used in verification contexts where the
user has a bit of paper and sees something on the screen and is asked a
question "do these things match?"

If there are two algorithms to choose from, there are potentially two
fingerprints to choose from, and this process becomes more complicated.
the tool now has to either (a) first, ask the user which form of
fingerprint is on the bit of paper before displaying the fingerprint
(making fingerprint comparison a multi-roundtrip operation), or
(b) present both and hope the user knows to ignore one or the other
(similarly to how web browser certificate dialogs look, and we know how
well that works).

Either of these outcomes make this particular use case -- which already
has bad usability -- worse.

Arguably, we shouldn't encourage this use case at all, and should
replace it with something like "type in the expected fingerprint and
we'll tell you if it matches".  If we make that decision, the argument
for multiple fingerprint algorithms might be OK.  But while i use this
workflow myself, i think most users would find it too burdensome.
Reading high-entropy hexadecimal (or base64 or whatever) is bad enough.
typing it in is even worse.

    --dkg

---

From: ianG <[email-masked]>
Date: Fri, 23 Oct 2015 21:43:43 +0100

> arrangement for OpenPGP fingerprints.

Yes, giving users "choice" in cryptographic algorithms is a bad idea in 
general.

> typing it in is even worse.

IFF it is decided that there are two incompatible fingerprint schemes 
then they should be made unconfusable.

One way to do this is to use PHB's leading byte or nibble indicator.

Another way to do this would be to split the lengths such that one set 
of lengths is valid in one MD, and another is valid in another MD.  SO 
e.g., anything 8, 12, 16, 20 bytes long is SHA2 and 10,14,18,22 are 
reserved for SHA3, etc.

(Just for explanatory purposes.  PHB also has his 5-byte method which I 
quite like.)

iang

ps; just to re-iterate my view on multiple algorithms, I've yet to see a 
compelling argument, being one that is actually founded rather than 
circulated or based on claims of caution.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 26 Oct 2015 12:02:33 -0400

> arrangement for OpenPGP fingerprints.

As I pointed out, it isn't really a choice. Every client has to be
able to verify any fingerprint that can be generated.

> question "do these things match?"

Again, I did point out that issue. If you have more than one digest
algorithm, each has to result in a unique presentation. Hence the need
for tagging.

> (similarly to how web browser certificate dialogs look, and we know how

Only if either you do it wrong or decide on one algorithm and pick the
wrong one.

That is the same problem that comes up with attacks involving
presenting a SSH key to OpenPGP or vice versa.

> typing it in is even worse.

I don't think that is right either. I would prefer to make comparison
a lot easier by going for visual comparisons. Base32 is a lowest
common denominator approach. I would like to have an alphabet of 2^16
words and 2^16 images as well.