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

From: Werner Koch <[email-masked]>
Date: Thu, 17 Sep 2015 20:41:56 +0200

Hi!

I'd like to get opinions on one specific aspect of a new fingerprint
format in 4880bis.

In the past we bound the fingerprint format to the key packet version:
v3 keys used MD5 and v4 keys SHA-1 fingerprints.  This gained us the
benefit of having a bijective connection between fingerprint and key.

For X.509 and ssh (OpenSSH), there has always been an uncertainty which
fingerprint to use because there is no well established standard for it.
For a long time MD5 was used but then some users switched to SHA-1, and
meanwhile SHA-256 is also seen more often.  These fingerprint formats
can easily be distinguished by their length and thus the format itself
is not a problem.  However, if you ask users to verify the fingerprint
of a certificate and you given them SHA-1 but they have only access to
the MD5 fingerprint things starts to get wrong.  Complicated (human)
reasoning about the identity of a certificate needs to be done.

With OpenPGP is is easier: The specs say that a key is described by one
and only one fingerprint.  There is no way to assign a different
fingerprint to the the same key.

If we want to introduce a, say, SHA-256 fingerprint, the straightforward
way is to define a v5 key packet format which will be identical to the
v4 format with the exception of the packet version number (and maybe
rules on what algorithms to use with a v5 key) [1].

Such a v5 format also means that it is not possible to switch to the new
fingerprint format for existing v4 keys.  The v4 keys would continue to
use SHA-1 fingerprints.

Some people claim that a SHA-1 fingerprint might soon be problematic due
to collision attacks.  If we assume that this is indeed the case, the
question is whether switching to SHA-256 for the very same key does
actually help: The mix of different fingerprints for the same key will
lead to the same confusion we have seen with X.509 and ssh.  Further, if
there is a need to switch to a stronger fingerprint format for the same
key, should the user not also assume that the use of the key has already
been compromised and it is time to create a new key?

Given that we are expecting to soon switch from RSA to ECC for improved
security and that the current base of OpenPGP implementations supporting
ECC is quite small, I would recommend not to allow a second fingerprint
format for v4 keys but to bind a new fingerprint format to a v5 key
packet version.

Shalom-Salam,

   Werner

[1] I recently talked to the guy who asked a long time ago for a hard
expiration time in a future key packet format.  He is not anymore
interested in this and thus other technical changes to the key packet
format a not needed.

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

---

From: [email-masked]
Date: Thu, 17 Sep 2015 18:05:36 -0400

On 9/17/2015 at 2:44 PM, "Werner Koch"  wrote:
Some people claim that a SHA-1 fingerprint might soon be problematic
due
to collision attacks.  If we assume that this is indeed the case, the
question is whether switching to SHA-256 for the very same key does
actually help: The mix of different fingerprints for the same key will
lead to the same confusion we have seen with X.509 and ssh.  Further,
if
there is a need to switch to a stronger fingerprint format for the
same
key, should the user not also assume that the use of the key has
already
been compromised and it is time to create a new key?

=====

If Collision attacks become viable for SHA-1 fingerprints, then they
would probably also become viable for subkeys as well, and it might be
possible for an attacker to generate a subkey with a collision for the
cross-certifying signature, and be able to graft a false subkey onto a
master key with a SHA-1 signature, which would definitely be a key
compromise.

so, yes,  it would be reasonable to have a new V5 format for the new
fingerprint.
vedaal

---

From: Werner Koch <[email-masked]>
Date: Fri, 18 Sep 2015 14:20:53 +0200

> cross-certifying signature, and be able to graft a false subkey onto a

You mean the back signatures (Primary Key Binding Signature), right?
They are done directly on the key material and not on the fingerprint.
Thus back signatures can be updated to SHA-256 without problems.

Shalom-Salam,

   Werner

---

From: ianG <[email-masked]>
Date: Sat, 19 Sep 2015 16:19:12 +0100

Hi Werner,

> benefit of having a bijective connection between fingerprint and key.

I'm hugely on that side.  I'll always vote for that.  I even staked my 
rep on it :)

http://iang.org/ssl/h1_the_one_true_cipher_suite.html

Which came directly from the experience of hacking PGP & OpenPGP in 
Perl/Java as part of Cryptix.  The tears, the fears, the costs.

So:  the only choice for me is which hash you pick for v5.  If you want 
another one, start planning for v6.

> fingerprint format for existing v4 keys.  The v4 keys would continue to

Yes.

> been compromised and it is time to create a new key?

The message is clear to me:  "Start upgrading to v5."

Put your energy in the future.  Put your users' energy into the future...

> interested in this and thus other technical changes to the key packet

iang, who not everyone agrees with...

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 21 Sep 2015 11:13:48 +0200

ianG <[email-masked]> writes:

> So:  the only choice for me is which hash you pick for v5.  If you
> want another one, start planning for v6.

+1

I believe sub-negotiating in security protocol leads to obscure problems
and makes security evaluation harder.  If we can avoid that, and that
appears to be the case, I'm all for it.

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?

What would be the relevant options be anyway?  SHA-256, BLAKE2,
SHA3-256, SHA-512, CubeHash?  Would there be value in being able to use
variable length SHAKE variants?

/Simon

---

From: ianG <[email-masked]>
Date: Tue, 29 Sep 2015 09:54:50 -0400

> variable length SHAKE variants?

There are a few reasons to go to SHA3 or SHAKE, as far as I see it.

1.  It leaps us ahead by about a decade in terms of cryptographic 
experience.

2.  It can do any size so we can use the same algorithm for all the 
different uses, without getting into esoteric arguments about 
truncation.  Indeed this is intended -- although rare, the team that 
made SHA3 felt our pain and improved our interface to the black box 
known as the message digest.

3.  This further leads to the possibility that if we get scared of the 
"short" length, we can just lengthen the base array and let the software 
work it out.  Similar to PHB's concept, we could just pre-ordain some 
applicable lengths that work for all purposes.

4.  The same base algorithm can be used as a symmetric AE cipher.  This 
leads to the possibility of one algorithm family giving most of the 
cryptographic needs (we'd need an asymmetric one too).  The development 
savings and the size savings are not to be sniffed at:  leads to small 
lightweight deployments e.g., on IoT and many more and maintainable 
language implementations.

5.  As a higher level meta-advantage, getting us away from the alphabet 
soup approach to protocol design might clarify to us why it is that 
there is an advantage in having more than one of everything around.

iang

---

From: "Daniel A. Nagy" <[email-masked]>
Date: Tue, 29 Sep 2015 16:26:03 +0200

Hi,

I fully support the "One True Cipher Suite" paradigm of Ian. At Ethereum
(which is where I currently work), we have had quite a long explorative
discussion about the choice of THE hash function, and we came out in
favor of SHA3 (Keccak) for a multitude of good reasons most of which
apply to OpenPGP as well. I believe that the most important documents
from that debate are publicly available, but if necessary, I am willing
to repeat the arguments in a nutshell.

Furthermore, I also believe that if OpenPGP finally leaves the
convoluted CFB variant behind and goes for stream ciphers, SHAKE has
some very clear benefits over AES-CTR, chief among them that by using a
closely related hash function and stream cipher, we follow the "keep all
your eggs in one basket and watch that basket" principle; in other
words, we present a smaller cross-section to potential attackers.

Bests,

Daniel

On 2015-09-29 15:54, ianG wrote:
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 29 Sep 2015 14:40:11 -0400

> rules on what algorithms to use with a v5 key) [1].

Thanks for raising these points, Werner.

It should be straightforward to take the key material from an existing
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.

The difference here is that existing OpenPGP certifications made against
the key wrapped in v4 public key packet won't be applied to the "new" v5
public key.  Similarly, existing revocations or rejections of the old
key won't be applied to the "new" key.  That is, the same key material
presented as a new version is effectively treated as a distinct key no
matter what.

i personally find the argument about wanting bijectivity pretty
compelling.  If we can say with confidence that one OpenPGP object has
exactly one fingerprint format to use, that should greatly simplify
matching and verification.

So far, all responses in this thread have been in favor of coupling the
version with the fingerprint choice.  Does anyone in the WG want to
speak against this, or should we treat it as a conclusive and move
forward on that basis?

         --dkg

---

From: Werner Koch <[email-masked]>
Date: Wed, 30 Sep 2015 08:00:51 +0200

> 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.

Salam-Shalom,

   Werner

---

From: Werner Koch <[email-masked]>
Date: Wed, 30 Sep 2015 08:18:54 +0200

> reasons to favor something else?

I see also several reasons to favor SHA-256:

 - SHA-2 has shown no weaknesses during the SHA-3 competition.

 - SHA-256 is the commonly used hash algorithm for OpenPGP messages and
   keys and thus available in all code bases.

 - Although not an issue for fingerprints, SHA-3 is slower than SHA-2.

 - On embedded systems SHA-512 has a substantially performance penalty
   over SHA-256.

Given that modern ECC requires a larger than 256 bit hash, I am not sure
whether the next point is valid:

 - If we would go for a newer hash algorithm, all implementations would
   need to support SHA-256 (and SHA-1) anyway to support existing keys
   and allow verification of existing signatures.  Also decryption of
   symmetrically encrypted messages may require SHA-256 for the S2K.

Shalom-Salam,

   Werner