Subject: Re: [openpgp] Fingerprints

From: Vincent Breitmoser <[email-masked]>
Date: Tue, 05 May 2015 23:26:17 +0200

On 20 Apr 2015, Derek Atkins wrote:
>>> Short fingerprints are important; if they are getting too long
>>> they won't serve a purpose because the public key could be used
>>> directly.
>>
>> If we use a 256-bit fingerprint for a 255-bit curve25519 key,
>> what's the point?
>>
>> * digest algorithm; we need preimage resistance; we do not need
>> collision resistance.
>
> So you're saying we can stick with SHA1?  ;)

I would like to pick up on this point again: What's wrong with 160 bit
fingerprints?  The bit length seems more than sufficient to cover any
Mooreian doubts, a more relevant issue would be weaknesses in the
hashing algorithm itself, where the status is that in its 20 years not
even a collision has been found for SHA-1.

Seeing talk about fingerprints which "still fit into one line" and
"maybe moving to SHA3-512" while at the same time asserting that manual
verification of fingerprints should still be a thing, I'm a little
concerned about the direction this is going...

 - V

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Wed, 06 May 2015 01:48:03 +0200

On Tue, 2015-05-05 at 23:26 +0200, Vincent Breitmoser wrote: 
> hashing algorithm itself,
Hmm but if it can be easily done, is there anything that speaks against?

I think hashes up to 512 bit are still commonly "accepted" (even with
just hex encoding)... and I see no strong reason why we couldn't move to
e.g. RFC 4648 base32.
Actually others do similar things as well (e.g. OpenSSH).

And if it doesn't hurt, I rather go for the stronger, even if it should
never become necessary.

> where the status is that in its 20 years not
At least no one publicly known ;-)

Cheers,
Chris

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 5 May 2015 21:34:56 -0400

>> hashing algorithm itself,

The problem isn't the bit length, it is the fact that it is really
hard for the IETF to endorse use of SHA-1 in some places but not
others. There is really no reason to think that the current attacks
make SHA-1 risky in the WebPKI but we are having to swap it out
anyway.

At some level, the cost of explaining why SHA-1 is safe for a
particular use outweighs the benefits of keeping it.

> Hmm but if it can be easily done, is there anything that speaks against?

I don't think so. Particularly if we are going to Base32 encoding and
make sure that there is no confusion between the legacy SHA-1
fingerprints and the new ones.

> Actually others do similar things as well (e.g. OpenSSH).

Which is why I would like to move to a fingerprint format that can be
used with any protocol. Do it once, do it right and we don't have to
do it again.

> And if it doesn't hurt, I rather go for the stronger, even if it should

We do not even need to decide on a strength. Just make is so that the
number of significant bits is however many bits that are provided. We
can all use SHA-2-512 or SHA-3-512 and truncate to 125, 150, 250...
bits as the application requires.

---

From: Vincent Breitmoser <[email-masked]>
Date: Wed, 06 May 2015 09:16:22 +0200

>> Hmm but if it can be easily done, is there anything that speaks

There is such a thing as over-engineering, and increasing a fingerprint
bit length upwards of 160 bits "just because we can" seems to go in that
direction.  160 bits is all the hashes ever calculated by the entire
bitcoin network bitcoin network times all the hashes ever calculated by
the entire bitcoin network.

Someone said "length is important", I wanted to bring that point back
into discussion.  I would really prefer not to have every user of
FuturePGP read 25 rather than 20 characters to people just because we
thought "why not" on this list.  The last thing openpgp needs is
stronger technical security assertions at the cost of usability.

 - V

---

From: Werner Koch <[email-masked]>
Date: Wed, 06 May 2015 12:53:33 +0200

> bit length upwards of 160 bits "just because we can" seems to go in that

We also need to consider policy requirements.  As Phillip already
mentioned it is hard to explain why SHA-1 is sufficient.  In particular
because we use it in a crypto context.  It seems to be hard enough to
explain why using SHA-1 would be sufficient to map a string to a
restricted character set (for DNS) even without any crypto context.

For example: RedHat did a FIPS-140 validation of Libgcrypt and this
required that RMD-160 is disabled in Libgcrypt.  Now, for historic
reasons GnuPG uses this hash algorithm to map user ids to fixed length
strings for use in trustdb.gpg.  With the Libgcrypt change I had to put
separate RMD-160 code into GnuPG to avoid regressions (only Libgcrypt
was validated).  Eventually the same will happen to SHA-1.

To be future proof we should get away from SHA-1 for fingerprints and
use SHA-256 (or SHA-512) instead.  The external representation and even
the internal use in OpenPGP is a different issue and I am all in favor
for truncating it to 32 bytes for internal use and printing only up to
20 bytes.  This avoids extra work and SHA-256 is anyway required.

Salam-Shalom,

   Werner

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

---

From: Vincent Breitmoser <[email-masked]>
Date: Wed, 06 May 2015 13:36:40 +0200

On 6 May 2015, Werner Koch wrote:
> To be future proof we should get away from SHA-1 for fingerprints
> and use SHA-256 (or SHA-512) instead.

I have no quarrel with changing the hash algo.  If it improves security
at no cost of usability or complexity - go for it.

> The external representation and even the internal use in OpenPGP is a
> different issue and I am all in favor for truncating it to 32 bytes
> for internal use and printing only up to 20 bytes.  This avoids extra
> work and SHA-256 is anyway required.

Sounds good to me.  I'm just afraid that if "something stronger" is
available, people are going to use it.  Design decisions and established
culture on top of the standard tend to be maximum conservative.  Sort of
if you don't use the "full fingerprint" you're not doing "everything you
can" and people will use all 32 bytes no matter if it was ever intended
that way.  That's not a huge deal, we just need to keep it in mind.

I would leave the fingerprint length at 20 bytes in the standard, if an
implementation chooses to use more internally that's up to them.
Defining the fingerprint to be 32 bytes, then adding "for printing, it
SHOULD be truncated to 20 bytes" seems silly.

 - V

---

From: "Christopher LILJENSTOLPE" <[email-masked]>
Date: Wed, 06 May 2015 11:33:16 -0700

<proto-hat off>

> SHOULD be truncated to 20 bytes" seems silly.

I think this is a reasonable approach.  The phrasing I would use would be something along the lines of:

Any implementation MUST accept a 20 byte fingerprint for validation, consisting of the first 20 bytes of the calculated fingerprint.
An implementation MAY output, or accept, a longer fingerprint, if desired.
An implementation MAY output, or accept, the legacy SHA-1 fingerprint, for interoperability, but it's use SHOULD be discouraged.

The use of RFC 4648 would make things easier, btw, and also signal the new fingerprint model.

The concept will be familiar to anyone who uses git, btw.

	Christopher

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

--
李柯睿
Avt tace, avt loqvere meliora silentio
Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc
Current vCard here: http://www.asgaard.org/cdl/cdl.vcf
keybase: https://keybase.io/liljenstolpe

---

From: "Christopher LILJENSTOLPE" <[email-masked]>
Date: Wed, 06 May 2015 11:34:42 -0700

Ooops, forgot to reassert the bit....

</proto-hat off>

On 6 May 2015, at 11:33, Christopher LILJENSTOLPE wrote:

> keybase: https://keybase.io/liljenstolpe_______________________________________________
> openpgp mailing list
> [email-masked]

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Wed, 06 May 2015 20:38:12 +0200

> fingerprints and the new ones.
Which is easily achieved when we add some algo/version qualifier as it
was propsed before.

> used with any protocol. Do it once, do it right and we don't have to
In principle I'd agree... apart from that I don't believe we'll never
have to do it again (in the sense of exchanging the algo).

However, as for the "core" standard I'd still only specify a simplest
form of a fingerprint string format.
e.g. something like
<algo/version>:<FPdata>
and then for the "current" algo/version e.g.
0:<base32 of the SHA3-512 FP>
(i.e. the length would be dependant on <algo/version>.

Any further specifications, like how to map this into URLs or that like
should probably go into a separate RFC.
As should any further "formats" like a QR code representation of the FP.

> bits as the application requires.
I'm a bit sceptical about that... I think we rather should specify some
lengths/format and at least not encourage implementations to choose what
they think would be enough (cause then we have folks like GNOME which
take the first and last byte or so *grin*)

Cheers,
Chris.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Wed, 06 May 2015 20:43:55 +0200

On Wed, 2015-05-06 at 09:16 +0200, Vincent Breitmoser wrote: 
> direction.
Technically you may be right, but I think it's nevertheless the wrong
paradigm to approach security... "wrong" of course in the sense that
there are different paradigms and I'm on the other side ;-)

Generally we don't know for sure what our attackers (especially the big
ones like NSA) are capable of (right now), but it's likely that they're
at least some years ahead in terms of research. Neither do we know for
sure how cryptoanalysis moves on.

My paradigm is to generally assume the worst case respectively
strengthen crypto the most possible so that it's still usable (in the
technical sense).

Cheers,
Chris.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 May 2015 16:38:27 -0400

> Which is easily achieved when we add some algo/version qualifier as it

One of the reasons I suggested the code numbers for SHA-2 and SHA-3
that I did earlier is they guarantee that the first letter of the
fingerprint will be M (SHA-2 'Merkle') or S (SHA-3 'Spongeworthy').
Thus ensuring that they are distinct from SHA1 fingerprints.

> have to do it again (in the sense of exchanging the algo).

The leading byte gives both the method of constructing the hash and
the algorithm to use. I suggest we define code points for SHA-2 and
SHA-3 using an identical construction approach.

> (i.e. the length would be dependant on <algo/version>.

I think we can go even simpler:

Fingerprint = Base32ify (BinaryFP)

BinaryFP = ID + H( HashedValue)
HashedValue =  <Content-Type> ':' <Data>

Since the MIME content registry does not permit entries with a colon
in the tag, this is guaranteed to be unambiguous. And since a
Content-Type can be defined for any data object that might need to be
hashed, it can support any content.

All the PGP related information would go in the <Data> field, so that
would include the PGP format version identifier, algorithm code, etc,
etc.

> As should any further "formats" like a QR code representation of the FP.

All that would be needed in the PGP spec would be a definition of the
PGP Key Packet and a MIME registration (if not already registered).

We should definitely split the consideration of QR codes etc out of
the PGP doc. We probably want to define the QR code in such a way that
a device can recognize that a QR code is intended to be a PGP key and
handle it appropriately. We also want to make sure we don't waste bits
in QR space. And it has to be possible to convert an ascii fingerprint
to QR format.

> take the first and last byte or so *grin*)

If we are using Base32 and character groups of 5 characters (7-2
rule), the keys naturally come in 25 bit increments.

A 125 bit fingerprint has 117 bits and looks like this:
MFRTK-NJSMF-STOMR-WG5ST-ONZXGA

If we go for 150 bits we get:
MFRTK-NJSMF-STOMR-WG5ST-ONZXGA-YDKZB

>From a security point of view, we really don't need to go beyond 128
bits unless we are planning to use 256 bit encryption.

I think that either of those is acceptable on a business card.

The QR code equivalent is manageable even without format tweaks (attached).

In 'under the covers' applications the user does not need to see, I
would hope we would support use of the 256 bit or full 512 bit
fingerprint. I would also hope we can use the possibility of an online
store to 'stretch' a fingerprint. If the user types in a 25 character
fingerprint, the system can get the rest off a key service.

---

From: Vincent Breitmoser <[email-masked]>
Date: Wed, 06 May 2015 22:43:03 +0200

On 6 May 2015, Phillip Hallam-Baker wrote:
> fingerprint.

Hm. Do you have a specific purpose for that in mind?

 - V

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 May 2015 17:07:51 -0400

> Hm. Do you have a specific purpose for that in mind?

Any time someone is using a WF-256 bit key.

But also in the notary systems used for timestamping and such

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Wed, 06 May 2015 23:31:12 +0200

> SHA-3 using an identical construction approach.
In principle I'd like to see that both algos can generally be used with
a future OpenPGP, given the different class (Merkle-Damgard vs Sponge),
generally for the FP and other areas.

But I guess the majority here would want to have only one algorithm, at
least for the FP.
Is there any broad consensus already about SHA2 vs. SHA3 (except the
traditionalist argument)?

> HashedValue =  <Content-Type> ':' <Data>
Isn't that what I've said? Or what is ID in your text?

At least I think the user should directly see the algorithm/version
without needing to decode the baseXXX.

> would include the PGP format version identifier, algorithm code, etc,
Nah... that's bad IMHO... I really would want to know which algo I use
without turning on some BASExx decoder (which doesn't mean that one
cannot include it there as well).

And what's the content-type then in your thinking, if it's not the algo?
Just the information "this is a OpenPGP fingerprint"?
Then as I've said previously,.. I think this doesn't need to be part of
the core standard of OpenPGP,... but if it would be really just a
handful of MIME types e.g. one for "OpenPGP fingerprint" I would neither
strongly oppose this.

> in QR space. And it has to be possible to convert an ascii fingerprint
I should perhaps notice again, that in general it's IMHO rather a bad
idea to standardise "fingerprint formats" which are not directly
readable (including QR code or things like OpenSSH's ASCII art version
of the FP).

> bits unless we are planning to use 256 bit encryption.
(The later, ) which would be nice... 

We already have curves for that...

Cheers,
Chris.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 May 2015 18:14:35 -0400

> traditionalist argument)?

The folk I have spoken to were of the opinion that the SHA3 contest
actually confirmed people's confidence in SHA2. So I don't see a need
to jump to the next bright shiny object.

SHA3 is supported in pretty much every stack now, SHA3 is still a bit
of a work in progress.

So I would suggest that SHA-2-512 be REQUIRED and SHA-3-512 be RECOMMENDED.

> without needing to decode the baseXXX.

Yes, and this should hold for both the base32 version and when doing a
hex dump of a binary fingerprint. So the ID should be a byte and the
top 5 bits should result in a letter in the range G-Z.

> cannot include it there as well).

The hash algorithm id is in the <BinaryFP>. The <data> field needs to
have the algorithm of the public key.

> Just the information "this is a OpenPGP fingerprint"?

yes.

> handful of MIME types e.g. one for "OpenPGP fingerprint" I would neither

I think the OpenPGP system would end up using at least two codes, one
would be 'OpenPGP fingerprint' and the other would be for 'Something
like TRANS that does not have ASN.1'.

Fixing key signatures in time has a lot of security value that I can
demonstrate in terms of work function.

---

From: ianG <[email-masked]>
Date: Thu, 07 May 2015 13:09:25 +0100

+1 on PHB's plan.

>> take the first and last byte or so *grin*)

For b-cards and so forth it isn't nearly as important to specify a 
length or strength for security reasons.  People can roll their own 
business cards any time they want to change, and often they want 
something shorter so that it fits nicely.  This is a manageable risk.

> MFRTK-NJSMF-STOMR-WG5ST-ONZXGA-YDKZB

Concur - this is good.  It also nicely skips 160 bits, so we can even 
imply the new hash from the length.

> fingerprint, the system can get the rest off a key service.

Right, under the hood, use the full hash.  Why muck around?

iang

---

From: ianG <[email-masked]>
Date: Thu, 07 May 2015 13:14:52 +0100

> So I would suggest that SHA-2-512 be REQUIRED and SHA-3-512 be RECOMMENDED.

All the above is reasonable.  However there is one further argument in 
favour of SHA-3 which is that it is going to come in the form of a much 
larger / more powerful toolkit.  It's no longer "just a hash."

It has specific modes attached to it that can do, for example, AE, and 
that AE mode has (I gather) been used for the CAESAR competition.

Point being, there is a chance that we can do the whole symmetric part 
with only one algorithm... :-o

Now I know this will give people the heebie jeebies, so what I'd say now 
is that we delay a firm decision until NIST have published their spec on 
SHA-3 and then review it to get the true story.  My information is based 
on a presentation I saw by the Keccak team, so possibly I'm way off 
base.  NIST will clarify this all.

iang

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 May 2015 09:21:39 -0400

On Thu, May 7, 2015 at 8:14 AM, ianG <[email-masked]> wrote:
> It has specific modes attached to it that can do, for example, AE, and that
> AE mode has (I gather) been used for the CAESAR competition.
>
> Point being, there is a chance that we can do the whole symmetric part with
> only one algorithm... :-o
>
> Now I know this will give people the heebie jeebies, so what I'd say now is
> that we delay a firm decision until NIST have published their spec on SHA-3
> and then review it to get the true story.  My information is based on a
> presentation I saw by the Keccak team, so possibly I'm way off base.  NIST
> will clarify this all.

On the platforms I use, I can expect SHA-3 to arrive in due course but
it isn't going to expose that functionality without a completely new
API.

>From a design point of view it is clear that SHA-2 and SHA-3 are the
choices and one will be REQUIRED and the other RECOMMENDED. Which is
which has no immediate implications and does not even become an issue
until last call.

I have text and I have code for the SHA-2 version. I can get a
standalone draft done next week and then we don't need to keep
circling on this.