Subject: [openpgp] Followup on fingerprints

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Jul 2015 10:52:05 -0400

So following the discussion in Prague, I suggest:

* Remove most of the motivation discussion from the draft and all of the
bit that refers to stuff outside OpenPGP

* Keep the MIME content type as the domain separation mechanism. Define the
MIME Content types for OpenPGP vCurrent, PKIX SubjectKeyInfo and nothing
else. [1]

* Contact some usability types to ask about usability and changing up the
block sizes.

Does that work for folk?

[1] We can do the SubjectKeyInfo thing as a separate registration but it
means more work processing an extra draft.

---

From: Werner Koch <[email-masked]>
Date: Wed, 29 Jul 2015 10:37:00 +0200

> * Contact some usability types to ask about usability and changing up the

OpenPGP does not specify a user interface but the wire format.
Obviously we use the most compact format there which is the plain binary
format.  The questions are

  - Do we need to explicity indicate the fingerprinting scheme (SHA-1 or
    SHA-256, or whatever) in the binary represenation.
  
  - Do we need truncation and how do we indicate a fingerprint scheme
    then given that it can't be deduced from the length.

  - Should we bind a certain fingerprint scheme to a public key packet
    versions as we did in the past (v3 = MD5, v4 = SHA1, maybe v5 =
    SHA256 with keyid being the leftmost octets).  Or is it okay to
    allow for multipe fingerprint schemes for the same key.

Salam-Shalom,

   Werner

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Jul 2015 10:31:22 -0400

OK one thing from the meeting I forgot to mention, the security
considerations have to address the use of a birthday attack by someone
generating keys.

If we are doing ECC, it is quite practical for someone to generate 2^50
keys and then pick the two that match in the first 100 bits. This can then
be used for attacks, particularly if the keys are not enrolled in some sort
of blockchain.

The other bit I left out is the idea of compression. The idea here being
that the person generating the key looks for a fingerprint that has 0s for
the first n bits. Then the fingerprint starts with a version number that
says 'the first 32 bits are 0s' or whatever.

Yet another bit that should be mentioned in the security considerations is
vanity fingerprints which are going to be more popular with all 26 Latin
letters to choose from. And those are a bad idea for the reason given in
the meeting. If my key starts off 'MERLI-Nxxxx' there is a temptation to
only check those bits.

Two important advantages of compression is that it provides an alternative
to vanity fingerprints (shorter is better than fancy for most folk) and the
work factor is not reduced by the birthday attack.

Without compression, a 100 bit fingerprint is 20 characters and 150 bits is
30. The work factor for a birthday attack are 2^50 and 2^75 respectively

With 32 bits of compression, the same strength against third party attack
is achieved. with 14 and 24 characters. The work factor for a birthday
attack are 2^66 and 2^81 respectively

> format.  The questions are

That is how we used to work in the 1990s. Since then we have had to do
internationalization and such.

As I started saying back then, the hardest part of a transaction to secure
is the first/last two feet between the user's head and the screen.

>     SHA-256, or whatever) in the binary represenation.

Yes, totally. I am suggesting we put code points in for the SHA-2-512
digest and the SHA-3-512 digest.

The reason for going for the big digest even though we plan to truncate is
that gives us maximal insurance against a compromise. These are the trust
axioms of the system.

>     then given that it can't be deduced from the length.

My preference is to just truncate and use the inferred length. That allows
us to minimize the amount of data we need to put in front of the user
without compromising security.

Lets say that in 2020 Alice meets Bob and they exchange their fingerprints
via a 150 bit QR code. Alice's smartphone goes to the mesh and pulls the
corresponding profile which has Bob's key and full 512 bit fingerprint. The
phone then stores the big fingerprint for Bob in her contacts directory.

I cannot imagine wanting to rely on a contract signature without pulling
the full record.

>     allow for multipe fingerprint schemes for the same key.

This is the 'domain separation' issue that was mentioned in the meeting.

I believe that we have to be able to revise the algorithm used to revise
the fingerprint and the format of the data being formatted independently.

As far as OpenPGP goes, the version indication inside the key packet should
be sufficient for v5. The only reason the version indication would not be
sufficient would be if a completely radical change to the format was being
considered such as moving all the structures to YANG, CBOR, JSON or JSON-B.

The proposal I have made is capable of dealing with that type of change
with clean cryptographic separation of the content domains.

---

From: Werner Koch <[email-masked]>
Date: Wed, 29 Jul 2015 17:06:45 +0200

> internationalization and such.

I can't see what internationalization has to do with the binary
representation of a fingerprint.  As I said RFC-4880 is about the wire
format and not about user interfaces: It tells how to compute a
fingerprint and that it is the 16 octet MD5 hash or the 20 octet SHA-1
hash.  Now that a fingerprint is printed like this

pub   dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31]
      Key fingerprint = 8061 5870 F5BA D690 3336  86D0 F2AD 85AC 1E42 B367

is the choice of the concrete implementation.  It is an interesting idea
to have a common way of representing fingerprints to the user or in an
URL but that is not in the scope of RFC-4800bis.

> digest and the SHA-3-512 digest.

Until now we have bound the format of the fingerprint to the version of
the public key format.  The fingerprint for OpenPGP is a well defined
and internally used property of OpenPGP.  This avoids multiple
fingerprints as we see with X.509 which does not have a specification
for a fingerprint at all.

> My preference is to just truncate and use the inferred length. That allows

By truncation I mean an arbitary truncation like what we do with keyids.
Those 64 keyids are for example used to locally lookup the secret keys
for decryption - there is no need to have security here because it is
just a convenience method (cf. wild card keyids)

> the fingerprint and the format of the data being formatted independently.

Again, OpenPGP does not specify how to format a fingerprint.  That is
and should stay out of scope for _this_ RFC but may be an additional
item for the WG.

> considered such as moving all the structures to YANG, CBOR, JSON or JSON-B.

The OpenPGP format is the OpenPGP format and not BER, PER, XML, or JSON.

Salam-Shalom,

   Werner

---

From: Vincent Breitmoser <[email-masked]>
Date: Thu, 30 Jul 2015 01:34:09 +0200

On 29 Jul 2015, Phillip Hallam-Baker wrote:
> If we are doing ECC, it is quite practical for someone to generate
> 2^50 keys and then pick the two that match in the first 100
> bits. This can then be used for attacks, particularly if the keys
> are not enrolled in some sort of blockchain.

What sort of attacks are we talking about here?

> The other bit I left out is the idea of compression. The idea here
> being that the person generating the key looks for a fingerprint
> that has 0s for the first n bits. Then the fingerprint starts with a
> version number that says 'the first 32 bits are 0s' or whatever.

What do you mean here by "looks for"? Doesn't this effectively just
limit the bitsize of used fingerprints?

 - V

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 29 Jul 2015 23:53:21 -0400

> just a convenience method (cf. wild card keyids)

I'm not sure we should try to specify this kind of implementation
shortcut.  If a machine has a full fingerprint available to it (as it
does if it has the keys themselves), expecting any lookup to be indexed
by the full fingerprint seems like a reasonable expectation, and there's
no need to get into hashtable-style bucketing implementation details as
part of the RFC.

> and should stay out of scope for _this_ RFC but may be an additional

The sense i got of the room in Prague was that there were mixed feelings
about this point.  In practice, the fingerprint seems to be most often
used when there is a human in the loop, and in that scenario, the
textual representation of the fingerprint is indeed relevant.  If two
humans are comparing fingerprints, or a human wants to pass a
fingerprint to another human on a business card or sticker, then an
unambiguous strong representation (not bits on the wire) is important.

The only place where the fingerprint is used explicitly as part of wire
format in RFC4880 is in the designated revoker subpacket, and on this
list in the past there seems to have been no objection to replacing that
with a full public key packet as a way of avoiding concerns about weak
fingerprinting entirely (i'm hoping we can address this change in
4880bis).  So the wire format concerns aren't relevant to this case.

The other place where a fingerprint is used concretely is in HKP, as a
lookup string.  But again, here, it's not a bit-for-bit wire format.
The fingerprint in hkp is transmitted as an ascii string of hexadecimal,
which is human-readable (to map to an HTTP query parameter that a human
could type or paste into a web form).

As a result, it looks to me like a visual/textual representation of a
fingerprint could be in-scope for a 4880bis, if the WG wants to take it
on.

> The OpenPGP format is the OpenPGP format and not BER, PER, XML, or JSON.

If we're suddenly defining an entirely new OpenPGP packet format, then
we could indeed move to one of these other models.  But that seems like
a pretty radical change to me, though, and not the incremental
improvement/cleanup we're chartered for.

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 30 Jul 2015 00:04:11 -0400

> considerations have to address the use of a birthday attack by someone

I'll echo Vincent here and ask what specific attack you're concerned
about.

My current understanding of OpenPGP fingerprints is that we do not need
collision resistance as a property of the fingerprint mechanism.

We've discussed the possibility of birthday attacks against fingerprints
by someone generating keys before, and i've yet to hear a concrete
description of any attack that this permits.  If there is such an
attack, then we need to be really concerned about it now, since the
current fingerprinting mechanism (SHA-1) is likely subject to a birthday
attack by a motivated and well-financed attacker.

> be used for attacks, particularly if the keys are not enrolled in some sort

if we want to discuss append-only logs of key material, i'd be happy to
see that discussion happen formally in a separate thread, or over in the
certificate transparency WG where that sort of thing is already under
way.  I think dragging blockchains into a discussion on OpenPGP
fingerprint mechanisms is a distraction.

> says 'the first 32 bits are 0s' or whatever.
 [...]
> without compromising security.

These two proposals seem incompatible to me.  If you give me a
fingerprint that is shorter than the expected length, and both
mechanisms are available, how am i supposed to know whether you've given
me a truncated fingerprint or a "compressed" fingerprint?

> phone then stores the big fingerprint for Bob in her contacts directory.

Wouldn't the phone just store the key itself instead of the fingerprint?
Why does the fingerprint matter in this scenario after the initial
introduction?

         --dkg

---

From: Werner Koch <[email-masked]>
Date: Thu, 30 Jul 2015 08:34:35 +0200

> shortcut.  If a machine has a full fingerprint available to it (as it

Please have a look at Public-Key Encrypted Session Key Packets (Tag 1):

| The body of this packet consists of:
| 
|   * A one-octet number giving the version number of the packet
|     type.  The currently defined value for packet version is 3.
| 
|   * An eight-octet number that gives the Key ID of the public key to
|     which the session key is encrypted.  If the session key is encrypted
|     to a subkey, then the Key ID of this subkey is used here instead of
|     the Key ID of the primary key.
| 
|   * A one-octet number giving the public-key algorithm used.

This requires the 64 bit key id.  I doubt that anyone want to change
this basic packet - implementations would need to implement two
different types of these packet for no real benefit.

The ECDH algorithm also needs a 20 byte identification of the key and
thus we need a second truncation type here for non-SHA-1 fingerprints.

Thus having a way to compute a keyid from a fingerprint is required.
Quite some time ago this has already been discussed and the suggestion
was for a future fingerprint format to right truncate it instead of the
left truncation we do right now.

> used when there is a human in the loop, and in that scenario, the

The fingerprint is the unique identifier for a key and it has the nice
property that it has a fixed length.  It is used at a lot of places to
represent the key - not necessary for humans.

> humans are comparing fingerprints, or a human wants to pass a

Sure this is important for the use of an OpenPGP implementaions.  But it
is not required for the correct working of the protocol.  The protocol
is independet of the UI.

> format in RFC4880 is in the designated revoker subpacket, and on this

And the ECDH algo.

> with a full public key packet as a way of avoiding concerns about weak

I see no reason to do this.  It would require a lot of changes in
existing code because both method will need to be supported for backward
compatibility.  If also does not ease the real complexity which is to
evaluate whether that key is still valid (not revoked, not expired
etc.).  Supporting in addition a new type of fingerprint is much
simpler.

> which is human-readable (to map to an HTTP query parameter that a human

This just an encoding required by the keyserver protocol.  It is not
intended for humans.

> fingerprint could be in-scope for a 4880bis, if the WG wants to take it

If we begin to extend the scope to the UI we have no reason to reject
other UI things.  I do not think this belongs into RFC4880bis.
The human readable format of a fingerprint should either be in
implementations hints or in a separate RFC.

Salam-Shalom,

   Werner

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 30 Jul 2015 10:12:41 -0400

OK, so looking through the threads, I think we are talking at cross
purposes due to differences in terminology. For me a fingerprint is a
presentation of a digest to be read by a human.

Getting the nomenclature consistent may seem unimportant but it is actually
50% of getting a spec right. I suggest the following.

We have a sequence of two modules as follows.

Digested content = The input into the fingerprint digest function.

Fingerprint digest function = Some function involving SHA-2/SHA-3 and a
version identifier.

Tagged Digest/Binary Fingerprint = The output from the Fingerprint digest
function.

Presentation Function = Converts the Binary Fingerprint for human
readability. Probably involves truncation, BASE32 and inserting dashes.

Fingerprint = What the user sees.

Internally, the Tagged Digest/Binary Fingerprint is the structure that is
closest to the existing OpenPGP 'fingerprint'.

> URL but that is not in the scope of RFC-4800bis.

Back in the 1990s, we could ignore the user interface layer completely.
Those times are past. For OpenPGP to work in the real world, people have to
be able to write fingerpints on their business cards in ways that different
implementations can interpret.

When we designed URLs, they were not designed to be written on the side of
a truck but they were designed to be printed in the references section of a
scientific paper.

> for a fingerprint at all.

By 'format of the fingerprint' you seem to be referring to the format in
which the digested content is presented, i.e. the input to the Fingerprint
digest function. I think it is better to have the version specify just the
Fingerprint digest function.

We can get domain separation between OpenPGP versions by putting a content
version somewhere in the Digested Content.

> just a convenience method (cf. wild card keyids)

There are two points at which truncation might occur. The Presentation
module really has to do truncation. Even 256 bits is too many.

We might want to truncate the binary fingerprint to 256 bits as well. The
reason for using SHA-2-512 is more rounds, not to get more output bits.

> and should stay out of scope for _this_ RFC but may be an additional

Absolutely. This should be a separate document from RFC4880-BIS

> The OpenPGP format is the OpenPGP format and not BER, PER, XML, or JSON.

One of the few things Rudy Guiliani ever said to me that made any sense is
that you can't expect every disaster but you plan for all the disasters you
can imagine and then you are most likely to be prepared for the one that
happens. So planning for an invasion by a zombie hoard might sound like it
is completely nuts. But that sort of planning might come in handy if you
were facing a major outbreak of Ebola.

I think its the same with extensibility. We can't predict every future
possible use of the spec and we shouldn't try. But if we can cover all the
possibilities we can imagine without undue burden on the spec, we maximize
the possibility that someone can build the extension that turns out to be
the killer app.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 30 Jul 2015 10:44:48 -0400

On Thu, Jul 30, 2015 at 12:04 AM, Daniel Kahn Gillmor <[email-masked]
> wrote:

> collision resistance as a property of the fingerprint mechanism.

That depends on the use cases you anticipate for OpenPGP and what you
expect people will build on top.

The thing is that OpenPGP is not just an email security application, it is
infrastructure. A lot of stuff is built on top of the spec that has nothing
to do with email.

That does not mean we have to support those applications. But it does mean
that we have to write a security consideration telling people we have (1)
considered the issue and that (2) either it isn't a problem or you should
do stuff that is going to be affected.

The concern here is that Mallet generates two keys that have the
fingerprints

Mxxxx-xxxxx-xxxxx-xxxxx-xxxx1 'M1' and .
Mxxxx-xxxxx-xxxxx-xxxxx-xxxx2 'M2'

Mallet joins an open source project which only takes the first 100 bits for
the fingerprint. He uploads the key for M1 to a keyserver.

He then commits a large number of malicious patches using M2 for
authentication. These are all authenticated against his public key M2 when
he does the commit but the repository uses the key sent in band and does
not keep the key for later verification.

At this point, any attempt to hold Mallet accountable is going to have to
rely on a human examining the logs and working out that Mallet must have
generated the malicious pair of keys. There is going to be no way to unwind
the thing automatically.

> fingerprint mechanisms is a distraction.

The connection is that each blockchain output can be used as an axiom of
trust. Since the purpose of fingerprints is to represent roots of trust,
this is a possible use case that the spec should be capable of
accommodating without opening up the question of how precisely that would
be achieved.

> me a truncated fingerprint or a "compressed" fingerprint?

Well, the fingerprint version tag would have to flag that encryption is
being used. So instead of the fingerprint being Mxxxx-.... (SHA2-512) or
Sxxxx-... (SHA3-512), it might be Xxxxx-...

> Why does the fingerprint matter in this scenario after the initial

OK, 'at least the 512 bit fingerprint'...

Which you do probably depends on if you are using ECC or RSA. With RSA,
those 2048 bit keys start to bulk up...

For my particular implementation, I want to be able to rotate encryption
keys on a monthly basis or any time a device is added or removed from a
user's profile. so I am using fingerprints of key signing keys rather than
end-entity keys.

As a general rule, it seems that you can solve pretty much any usability
problem at the cost of an additional key. Back in 1995, this would have
ground the whole net to a halt. Today it isn't a problem. Right now on my
testbed Alice has a personal profile of 3 keys, plus a device profile of 3
keys per device, plus individual keys for each use in application (1+1 per
device for email, 1 for 2 factor auth, 1 for admin, 1 for data encryption,
1 for drive encryption). So assuming Alice has 2 desktops, a laptop, a
tablet, a phone and a watch, that is 3 + 18 + 7 + 6 = 30 keypairs and an
additional one per month.

It might sound a bit extreme, but since I started in the business, machines
have gotten roughly a million times faster and have a million times the
memory. 30 keypairs instead of one does not seem like a big deal.

---

From: Wyllys Ingersoll <[email-masked]>
Date: Thu, 30 Jul 2015 15:15:45 +0000

> It might sound a bit extreme, but since I started in the business,
> machines have gotten roughly a million times faster and have a million
> times the memory. 30 keypairs instead of one does not seem like a big deal.
>

Really?  It sure does to me.  PGP suffers from numerous usability issues,
some of which are a result of implementation artifacts and some are
unavoidable due to the nature of security and the spec itself.  Making
things more complicated or breaking compatibility with widely used existing
implementations in order to satisfy an odd niche use case does not seem to
me like its advancing the cause in a helpful way.

People today balk at managing a single PGP keypair across multiple devices
and applications, how in the world would they be expected to deal with 30+
(and growing) keys?  Perhaps this is all handled automatically by whatever
scheme you are developing and the user would never know or care that there
are 30+ keys in their domain, but as described it seems way complicated.

Im in agreement with Werner that we should tread carefully in redefining or
overloading the meaning of a "fingerprint" beyond how it is already
specified in 4880.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 30 Jul 2015 11:42:25 -0400

> are 30+ keys in their domain, but as described it seems way complicated.

If you have complicated use cases, trying to make the spec too simple is a
mistake. It is probably also a mistake to dismiss someone's work as 'niche'
before you bother to read it. My approach to dealing with the usability
blunders in S/MIME and OpenPGP is to design the system in such a way that
the user does not need to be aware that they are using encryption except in
the very rare situation where they want to make sure that the message is
sent encrypted or not at all.

The use case I am dealing with is precisely the problem of managing keys
across multiple devices. And it is all entirely automatic.

As far as the user is concerned, they only really have one key like thing
that they need to worry about.

Right now, there aren't many implications for OpenPGP bis. The main
difference is working with a key signing key rather than the key itself.
But that is pretty much inevitable if you want to deal with real world
problems like Alice wanting to make sure that she can encrypt her hard
drive and there is absolutely no way that it is at all possible.

But those are discussions to have on [email-masked].

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 30 Jul 2015 11:48:17 -0400

On Thu 2015-07-30 10:44:48 -0400, Phillip Hallam-Baker wrote:
> That does not mean we have to support those applications. But it does
> mean that we have to write a security consideration telling people we
> have (1) considered the issue and that (2) either it isn't a problem
> or you should do stuff that is going to be affected.

Completely agreed that the security considerations should make a point
of calling out what we think are legitimate and illegitimate uses of a
fingerprint.

> generated the malicious pair of keys. There is going to be no way to unwind

In either scenario, the committed code is done by Mallet, who was
explicitly authorized by the system to commit code.  So the failure here
is one of auditing, right?

And i think the implementation recommendation that would solve the
auditing problem here is "do not store fingerprints when you could be
storing keys" -- right?

Are there any other attacks we should be aware of due to failures of
collision resistance in the fingerprint?

> trust.

I don't know what an "axiom of trust" is, or why i would believe that
anything coming out of the blockchain would be one.  The properties i
think you're asking for are those of a global, append-only log.  whether
that's implemented by a blockchain or not seems like an implementation
detail.

> Since the purpose of fingerprints is to represent roots of trust, this
> is a possible use case that the spec should be capable of
> accommodating without opening up the question of how precisely that
> would be achieved.

Sure, so i think we're saying that fingerprints should be well-defined
enough to be entered into a global append-only log.  Do we need more
than that?

> Sxxxx-... (SHA3-512), it might be Xxxxx-...

By "encryption" do you mean truncation or "leading-zero compression"?
it seems like we're starting to come up with multidimensional
representations of fingerprint formats.  I'm already uneasy with the
idea of having multiple forms of fingerprint -- if i'm given form M on
my peer's business card, and then i'm shown a key by my software that
uses form S (or form XS or form XM or whatever) how am i supposed to
compare them?

>> Wouldn't the phone just store the key itself instead of the
>> fingerprint?  Why does the fingerprint matter in this scenario after
>> the initial introduction?
>
 [...]
> memory. 30 keypairs instead of one does not seem like a big deal.

Following this logic, i think the answer is still that the endpoints
should store the keys that they think are currently valid and not the
fingerprints.  Fingerprints aren't for storage, they're either for
discovery or for verification.

          --dkg

---

From: Vincent Breitmoser <[email-masked]>
Date: Thu, 30 Jul 2015 18:45:05 +0200

> OK, 'at least the 512 bit fingerprint'...

How are we even back to talking about 512 bit fingerprints?  I'm getting
a feeling we are starting to repeat everything that was discussed in the
original "fingerprints" thread here.

 - V

---

From: Derek Atkins <[email-masked]>
Date: Fri, 31 Jul 2015 09:28:45 -0400

>> generated the malicious pair of keys. There is going to be no way to unwind

Why?  M1 and M2 are completely different fingerprints, unless you're
assuming that the x's are the same.  If the x's are the same that means
that Mallet has performed a 2^50 level attack to get 100 bits to match!
How long and how much energy does Mallet have to do this?  It's
certainly not something s/he is going to do over a long weekend!

> collision resistance in the fingerprint?

I'll note that this attack isn't due to a failure of collision
resistance in the fingerprint.  It's an attack due to the application
(on top of OpenPGP) truncating the fingerprint and throwing away extra
data.

Personally I don't see this as a bug in OpenPGP -- the data is there in
the OpenPGP data structures.  I see this as a bug in the application
built on top of OpenPGP that is throwing away data.

It's also an authorization issue; at some point someone needed to
authorize the M1 and M2 keys to commit, so someone *saw* the full
fingerprint at some point.  The fact that someone looked at the full
fingerprint and then threw away 60 bits just means they did a poor
design.

[snip]
> discovery or for verification.

Or identification (e.g., the fingerprint/keyID of a signing key).  But
yes, the full key should be stored on the service when Mallet
registered.  There's yet another bug in the service (not OpenPGP) -- not
storing the keys of authorized users.

>           --dkg

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 31 Jul 2015 14:31:11 -0400

> certainly not something s/he is going to do over a long weekend!

Not with RSA keys. With ECC keys, different matter entirely.

> (on top of OpenPGP) truncating the fingerprint and throwing away extra

Which is makes this a Security Consideration. If people build 'stuff' on
top of OpenPGP as a foundation then they have to understand what the
foundation is designed to support.

I think a 25 character / 125 bit fingerprint is going to be fine. BUT there
are two issues I don't want to come up. One is someone builds something
that depends on the fingerprints being collision resistant and blames it on
the spec. The second is that some yahoo works this out again in five years
time and writes a paper claiming to have 'broken' the spec.

---

From: Vincent Breitmoser <[email-masked]>
Date: Fri, 31 Jul 2015 20:54:43 +0200

On 31 Jul 2015, Phillip Hallam-Baker wrote:
> I think a 25 character / 125 bit fingerprint is going to be
> fine. BUT there are two issues I don't want to come up. One is
> someone builds something that depends on the fingerprints being
> collision resistant and blames it on the spec. The second is that
> some yahoo works this out again in five years time and writes a
> paper claiming to have 'broken' the spec.

We can just mention that fingerprints are not (meant to be) collision
resistant in the spec, that should take care of that.

 - V

---

From: ianG <[email-masked]>
Date: Sat, 01 Aug 2015 01:53:19 +0100

> URL but that is not in the scope of RFC-4800bis.

I thought we were agreed on all that and there was a separate draft that 
PHB had written that just covered fingerprints for the user?

Ie, we've cut this out of 4880(bis) because it has merit but it doesn't 
belong there.

iang (mystified, am I imagining this separate document?)

---

From: Gregory Maxwell <[email-masked]>
Date: Sat, 1 Aug 2015 01:29:02 +0000

On Wed, Jul 29, 2015 at 2:31 PM, Phillip Hallam-Baker
<[email-masked]> wrote:
> other bit that should be mentioned in the security considerations is
> letters to choose from. And those are a bad idea for the reason given in the
> meeting. If my key starts off 'MERLI-Nxxxx' there is a temptation to only
> check those bits.

To be clear, there are two attack vectors I'm aware of in the space of
user-factors around digest for visual comparison by users.

One is that users are more likely to trust vanity identifiers
(fingerprints that spell out specific words), "it says right there in
the fingerprint, it must be right".

The second, is that users will tend to much more strongly compare only
the vanity portion and ignore the following line noise; and thus be
more vulnerable to substution than they would be with ordinary
randomly selected identifiers; as the attacker need focus only on
matching the vanity part (which will necessarily be small owing to the
computational resources of the actual user).

This conjecture has been experimentally validated both with Bitcoin
addresses (base58) and (especially) Tor hidden services (base32): At
one time there were several hundred silkroadXXXXXX onions addresses
active and being used to scam people.

I don't think there is much room left to debate that schemes which
better accommodate 'vanity' identifiers are more vulnerable in
practice.

Devoweled encodings seems somewhat safer in that they're less likely
to get appriciable vanity use (and also less likely to spell offensive
words).

Beyond your suggestion to make fingerprints purposefully expensive to
create, another possibility it encouraging comparison methods which
are more robust.
E.g. here is a cut-and-choose based scheme I had previously
implemented--  it uses a much larger digest and then encourages the
user to compare an actually random subset of it:

https://en.bitcoin.it/wiki/User:Gmaxwell/visual_fingerprint_comparison

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 31 Jul 2015 21:49:08 -0400

> iang (mystified, am I imagining this separate document?)

You are riight.

https://tools.ietf.org/html/draft-hallambaker-udf-00

I will rename the next one with OpenPGP in the title so the search tools
can find it. The plan is a separate document that essentially only tracks
stuff related to OpenPGP but can be built on by others elsewhere.