Subject: [openpgp] Mining protection in fingerprint schemes

From: Bryan Ford <[email-masked]>
Date: Wed, 6 Apr 2016 17:00:04 -0300

Sorry for the mailing list bomb, but I wanted to get a few more thoughts on the list while they’re still fresh.  Moving back to the question of what the “fingerprint scheme” itself might look like (the function that takes an octet-string and produces an ASCII-string), which may not really be OpenPGP-specific…

One of the potential goals that’s been discussed is to give users some form of “fingerprint-mining protection”, or defense against attackers mining for keys with similar-looking fingerprints.  This could potentially be provided either by playing with “what gets fingerprinted” (the topic of the E-mail I just posted), or by playing with the fingerprint scheme itself (the topic of this E-mail).

Here’s one specific idea for a fingerprint scheme with configurable mining protection, which builds on ideas suggested earlier by Christian Huitema and Phillip Hallam-Baker and others:

* Key creation:  OpenPGP implementation first picks a hardness parameter H determining level of mining protection. Implementations could provide a reasonable default for this, while allowing power-users to tweak it if they want.  Iterate the following loop until successful:

	1. Generate a public/private key-pair.  Call this public-key K.
	2. Take a hash of K and some domain-separation context string, yielding a “nonce” N.
	3. Use nonce N as the nonce input in an Argon2 proof-of-work, using otherwise fixed, “reasonable” Argon2 configuration parameters.
	3. Compute a SHA-512 hash based on K and this Argon2 proof-of-work; this is the “pre-fingerprint”.
	4. Unless the resulting pre-fingerprint has exactly H leading bits/bytes, go back to step 1, retrying with a fresh keypair.
	5. Form the fingerprint to present to the user as a one-digit encoding of H followed by an encoding of the last 256 bits of the pre-fingerprint.

* Fingerprint verification/recomputation on PGP key import: take public-key K, hash it as above, compute Argon2 nonce N, run a single Argon2 PoW round, verify the resulting SHA-512 against the proposed fingerprint.  Compute correct resulting fingerprint based on the number of leading zero-bits found in the hash and the last 256 bits of the SHA512 output.

The potentially beneficial properties of this approach are:

- Once the public/private key pair is created, the fingerprint depends on the public key and nothing else: i.e., it is “key-canonical”, as per the preference DKG expressed, keeping things simple.

- Users (and OpenPGP implementations) can configure the hardness parameter, in particular gradually increasing it over time, so that the difficulty of fingerprint-mining attacks for newly-created keys can keep pace with the increasing computational abilities of attackers.  Average users shouldn’t necessarily be expected to see or be aware of this at all; they just get keys with stronger fingerprints when they use newer software/machines to generate them.

- The use of an Argon2 PoW step in the “inner loop” makes it more difficult for attackers to do fingerprint-mining just by being very good at computing SHAs - e.g., as PHB mentioned, by using a big bank of GPUs or a bunch of repurposed Bitcoin mining hardware.  We don’t want to make all fingerprint-verifiers solve a “big” Argon2 PoW (because the receiver might be a smartphone with limited memory for example), but even just including a small/moderate Argon2 PoW in the key-creation mining loop might reduce a typical attacker’s advantage considerably.

Just as an aside, this hybrid between Argon2 and Bitcoin-style mining is really just kind of a “poor-man’s” solution to what we really want, which is an easily-verifiable “slow hash” as Arjen Lenstra’s group proposed in this paper: https://eprint.iacr.org/2015/366 <https://eprint.iacr.org/2015/366>

Cheers
Bryan

---

From: Jon Callas <[email-masked]>
Date: Wed, 6 Apr 2016 15:39:52 -0700

I don't get it. What problem are you trying to solve. Along with the previous note -- the fingerprint is in fact merely a hash of the key. It's a handle you can use in a database to identify the key with a fixed string. That's it.

	Jon

---

From: Bryan Ford <[email-masked]>
Date: Thu, 7 Apr 2016 11:55:36 -0300

> On Apr 6, 2016, at 7:39 PM, Jon Callas <[email-masked]> wrote:
> 

The problem is that one of the most common uses of fingerprints in practice is to verify consistency.

A lot of the people I meet at conferences who use PGP at all tend to put their PGP key fingerprint on their business card.  People also put their PGP key fingerprints on their websites, etc.  Given the general unusability of the “web-of-trust” model as originally envisioned and the lack of any better form of effective PKI in the PGP ecosystem, this casual fingerprint verification often tends to be “the best we can do” in terms of actually ensuring that you have the key you think you have.

But when eyeball-verifying a fingerprint, how many people really look/compare beyond the first 10 digits or so?  Whether mentally or verbally, we’re all tempted just to say, “oh yeah, that’s the fingerprint that starts with …” and assume we’re done.

Which leaves a huge attack vulnerability, at least in principle (although I don’t know if it’s actually happened in practice).  Someone who wants to pass themselves off as me can simply spend a bit of time mining for a new PGP key whose fingerprint matches mine, or yours, in the first 10 digits or so, and perhaps the last few as well.  They post their key with my E-mail address on one or more PGP key servers, and people download it and assume it’s my key because it “looks like” the fingerprint on my business card or web site in the first and/or last digits, the only ones they actually look at.  They might not be able to fool everyone that way, but still it seems like a pretty serious concern.

The whole idea of providing some form of “mining-resistance” in a fingerprint scheme is to enable the key-owner to invest some effort at key-creation time, to ensure that any attacker who wants to try to mine for a key with a similar-looking fingerprint will have to invest a *lot* more time and effort, not just a little.

Does this make sense?

B

---

From: Jon Callas <[email-masked]>
Date: Thu, 7 Apr 2016 16:36:09 -0700

> On Apr 7, 2016, at 7:55 AM, Bryan Ford <[email-masked]> wrote:
> 
> * PGP - S/MIME Signed by an unverified key: 04/07/2016 at 07:55:36 AM
> 
> 

I believe I understand you.

You're complexifying key creation for a hypothetical, movie-plot attack.

	Jon

---

From: Bryan Ford <[email-masked]>
Date: Thu, 7 Apr 2016 22:12:06 -0300

> On Apr 7, 2016, at 8:36 PM, Jon Callas <[email-masked]> wrote:
>> On Apr 7, 2016, at 7:55 AM, Bryan Ford <[email-masked] <mailto:[email-masked]>> wrote:

This attitude, that IETF-standardized protocols should not attempt to address known or foreseeable weaknesses unless there are documented cases of those specific attacks happening in the wild *right now*, is one key reason Internet security is in such a horrific state.  When protocol designs only ever attempt to address attacks that have already been documented in the wild - and calling all other attacks “movie-plot” scenarios - by definition you’re always playing catch-up and attackers will always be ahead.  The pervasiveness of this attitude, while understandable, makes me sad.

In the case of fingerprint-mining, we actually do have documented evidence of that occurring, the most obvious and well-known being Facebook’s vanity .onion address.  The fact that Facebook was not maliciously attacking anyone else - in effect they were only “attacking” their own brand-name by mining for a public-key whose .onion address would look like it - does not change the fact that their action demonstrated that both the capability and the incentives exist in the real-world to mine for fingerprints that look similar to something-or-other.  If it so happened that the “real” Facebook was mounting this attack against its own brand, the next time it might be a fake Facebook imposter mounting the same attack against Facebook by creating a similar-looking vanity name and hoping users will fall for it.  The issue is not who or what the fingerprint-miner is trying to make their mined fingerprint look like; the issue is that such attacks are clearly practical.

Documented fingerprint-mining attacks have occurred in other domains too: for example, not too long ago I remember that it was found that the Ripple ledger was vulnerable to “Transaction ID” fingerprint-mining attacks that were actually being exploited, in which an attacker mined for low-numbered transaction IDs which would cause their transactions to get processed first and provide arbitrage opportunities.  Obviously the fingerprint-mining was for a fairly different purpose in this case, but still it’s another documented example of the same general class of weakness: i.e., an attacker mining for a hash-based fingerprint that looks kinda like something that will help him get what he wants in some way.

Bryan

---

From: "Hilarie Orman" <[email-masked]>
Date: Thu, 7 Apr 2016 19:27:59 -0600

>  Date: Thu, 7 Apr 2016 16:36:09 -0700

>	   Jon

Millions of people every year are victims of fake business card attacks.
I read that somewhere.

Hilarie

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 8 Apr 2016 06:30:07 +0000

Bryan Ford <[email-masked]> writes:

>Someone who wants to pass themselves off as me can simply spend a bit of time
>mining for a new PGP key whose fingerprint matches mine, or yours, in the
>first 10 digits or so, and perhaps the last few as well.  

We already have good data on that via SSH's fuzzy fingerprints, with tools to
generate and exploit them having been around for some years.  They're quite
effective.

>The whole idea of providing some form of “mining-resistance” in a fingerprint
>scheme is to enable the key-owner to invest some effort at key-creation time,
>to ensure that any attacker who wants to try to mine for a key with a similar-
>looking fingerprint will have to invest a *lot* more time and effort, not just
>a little.

I'm not sure if this is worth the effort, see "Do Users Verify SSH Keys?",
https://www.usenix.org/system/files/login/articles/105484-Gutmann.pdf.  The
solution isn't to try and patch up something that inherently doesn't work
(look at browser PKI for a twenty-year, and still running, example of trying
to do that) but to look for alternative approaches to dealing with the
problem.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 8 Apr 2016 08:20:56 +0000

Bryan Ford <[email-masked]> writes:

>This attitude, that IETF-standardized protocols should not attempt to address
>known or foreseeable weaknesses unless there are documented cases of those
>specific attacks happening in the wild *right now*, is one key reason
>Internet security is in such a horrific state.

Or it's the exact opposite, every Internet protocol is expected to defend
against every theoretically imaginable scenario, which means they have to
defend against literally [0] everything.

Since no protocol can defend against everything, what happens in practice is
that the most vociferous people involved in its design select a few things
they care about (the NSA, the mind control satellites, quantum cryptanalysis,
and the lizard people) and defend against that, and the fact that a phished
credit card and a commercial CA who'll sell you any cert you ask for can bring
down the whole house of cards is ignored.

So you need some means of deciding what's worth defending against.  "Is this
practical" and "would anyone ever bother doing this" are two reasonable
criteria for estimating what's practical.

Peter.

[0] And when I say literally I mean figuratively.

---

From: "Robert J. Hansen" <[email-masked]>
Date: Fri, 8 Apr 2016 04:45:41 -0400

> Or it's the exact opposite, every Internet protocol is expected to 
> defend against every theoretically imaginable scenario, which means 
> they have to defend against literally [0] everything.

There are three basic states a defender can be in: "of course I'm not
being surveilled", "maybe I'm being surveilled", and "of course I'm
being surveilled".  You want people to stay in the first category at all
costs: they speak more freely and with fewer safeguards.  You want to
keep people out of the latter category at all costs: they speak only
what's strictly necessary and use extreme countermeasures.  This leads
to the attacker's first rule: don't be seen.

Bryan's idea violates this.  Okay, so you forge a collision on some
of the digits... but you have absolutely no idea which digits the
defender will check.  Or, for that matter, if three days later the
defender will look at the business card and say "hey, that's not right".
Or... etc.  This is such a high-visibility attack, with such a risk of
putting a defender into an aware and alert posture, that I have trouble
imagining a halfway competent attacker who would ever want to use this.
It's a complete roll of the dice, with extreme consequences for failure.

---

From: Jon Callas <[email-masked]>
Date: Fri, 8 Apr 2016 11:32:32 -0700

> On Apr 7, 2016, at 6:12 PM, Bryan Ford <[email-masked]> wrote:
> 
> * PGP - S/MIME Signed by an unverified key: 04/07/2016 at 06:12:06 PM
> 
>> On Apr 7, 2016, at 8:36 PM, Jon Callas <[email-masked] <mailto:[email-masked]>> wrote:

The first rule of security is that you can't protect against all threats. This is why you do things like threat modeling.

I'm really sorry you're sad, but you said "although I don’t know if it’s actually happened in practice" -- which means that it's a hypothetical attack.

But now, below, you're saying it's not. Look, if you were in error and now know documented cases, when you didn't yesterday, that's cool. We can always revise.

> Documented fingerprint-mining attacks have occurred in other domains too: for example, not too long ago I remember that it was found that the Ripple ledger was vulnerable to “Transaction ID” finger…

Let me go on a small rant of my own.

There is a problem in OpenPGP that it is notoriously too hard to use. 

I use OpenPGP through a PGP Universal server, but I also use S/MIME. S/MIME is in my mailer darned easy to use! Heck, your email itself was signed with S/MIME, not OpenPGP.

If you make key creation harder, people will create fewer keys.

If you make database lookup from fingerprint to key harder (or more costly) that makes it harder and more costly.

What's the *benefit* we derive from this added complexity and time? 

Moreover, can this problem be solved in a higher-level system?

We need to have a quick way to turn a cryptographic key into a fixed lookup (database key). The naive solution is a hash of that key, with or without something else.

If we turn the "fingerprint" into something complex, then we need to have a new thing that does what the old fingerprint does -- a quick transformation of key into lookup. What should that be?

Let me give a proposal of a generic scheme:

One of the ideas we had a long time ago was that the "fingerprint" actually has two fields in it. A tag and a value. I'm still fond myself of the fingerprint that is 

<algorithm-id>:<algorithm-value>

but I'm not wedded to the syntax. I like the idea; I don't care about the syntax.

If that gets adopted, then we *could* have a high-compute fingerprint and encourage people to put them on their business cards.

Does that help?

	Jon

---

From: "brian m. carlson" <[email-masked]>
Date: Fri, 8 Apr 2016 21:50:53 +0000

> to do that) but to look for alternative approaches to dealing with the

I agree.  I think we're approaching this problem the wrong way.  The
approach I like is what OpenKeychain is doing with QR codes: you scan
the QR code, which contains the fingerprint.  No manual verification is
necessary.  We should design systems that make it easy for people to get
right, instead of trying to defeat people being lazy.  People are always
going to be lazy, and we should aim to have that have as little impact
on security as possible.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 08 Apr 2016 23:35:50 -0300

>   going to be lazy, and we should aim to have that have as little impact

I agree that entirely mechanized, user-friendly, non-MITM-able key
transfer is superior to asking humans to deal with fingerprints.

But this is not the use case for fingerprints -- we can ignore
fingerprints entirely if we're talking about mechanized key transfer
(and there's no reason that OpenKeychain needs to use the fingerprint --
for Ed25519 keys, they could just put the public key itself in the QR
Code)

However, we will still need fingerprints for the use case where people
meet up but don't have any machines handy that are capable of doing an
automated transfer.  We're going to need a transcribable or
copy/pasteable string for people to use in that case.  We're also going
to need such a string for the situations where people want to look up a
key in a directory someplace after having done such a non-mechanized
transfer.

So please, by all means, help people solve the "directory lookup" and
"in-person key exchange" use cases in user-friendly ways that do not
involve fingerprints.  But unless the WG is convinced that those
solutions can completely replace the fingerprint everywhere, we'll still
need to decide how to compute and structure the fingerprint.

The presence of better in-person schemes than fingerprint exchange do
suggest that making a complex fingerprint scheme is unlikely to be a
good use of the energy of the WG group, though.

It would be great to decide on something simple, unambiguous, and secure
soon so that we can focus on the harder work we have on our plate.

     --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 08 Apr 2016 23:49:10 -0300

On Fri 2016-04-08 15:32:32 -0300, Jon Callas <[email-masked]> wrote:
>   One of the ideas we had a long time ago was that the "fingerprint"
>   actually has two fields in it. A tag and a value. I'm still fond
>   myself of the fingerprint that is
>

The sense i got from the group was that we wanted one (and exactly one)
fingerprint for any given key.

the proposal above means that i could compute a fingerprint for key X,
and you could compute a fingerprint for key X, and then when we go to
compare them they could be different (because one of us chose a
different algorithm id than the other).  This makes fingerprint
comparison a crapshoot, or requires one side of the comparisons to
generate all possible fingerprints before they discover what the other
side has done.

     --dkg

---

From: Jon Callas <[email-masked]>
Date: Fri, 8 Apr 2016 22:35:49 -0700

> On Apr 8, 2016, at 7:49 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

Noted.

I will mention that the advantage of a generic scheme is that it doesn't have to be revisited later when there's a new cool hash function that we all should use.

But the real reason for bringing that back was to give Bryan a hand. I see what he's wanting to do. He's wanting to create something that I will call the "authentication string." 

At present, we use the key fingerprint as the authentication string. The mining protection he's suggesting isn't a bad thing. My raised eyebrow comes from conflating the two. We need to have a "DB handle" and I believe the DB handle needs to be easy to compute (key-canonical is an orthogonal issue). The fingerprint gets used all over the place, especially in its truncated form as key-id.

So a way to get both is to make them not the same thing. Have it so that the thing that you print on your business card is the authentication string, and the thing that the software is using a lot is the db handle.

As it is, there are "fingerprints" used all over the place that aren't the user-visible one anyway, because the user-visible one is the fingerprint of the top-level signing key.

So stepping back even further, to have our cake and eat it two, we want to separate the two functions.

Anything that does that seems like a win, not just generalized fingerprints.

	Jon

---

From: Werner Koch <[email-masked]>
Date: Sat, 09 Apr 2016 11:50:02 +0200

> for Ed25519 keys, they could just put the public key itself in the QR

Which would also encourage not to add a salt (creation timestamp) so
that there is no need to somehow also convey the creation timestamp.

Shalom-Salam,

   Werner

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

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 9 Apr 2016 13:55:42 +0000

brian m. carlson <[email-masked]> writes:

>The approach I like is what OpenKeychain is doing with QR codes: you scan the
>QR code, which contains the fingerprint.  No manual verification is
>right, instead of trying to defeat people being lazy.

Exactly, leave the computation to the computers.  No human should be expected
to compare 40 hex digits for an exact match, that's why we have computers.  In
fact the denser QR codes can store an entire key in the QR code.  Once it's on
your phone, you can use your method of choice to get it to other devices.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 9 Apr 2016 14:02:29 +0000

Jon Callas <[email-masked]> writes:

>So a way to get both is to make them not the same thing. Have it so that the
>thing that you print on your business card is the authentication string, and
>the thing that the software is using a lot is the db handle.

That would resolve my pet peeve with the authent strings.  It'd also require
modifying the keyring format to store the keyID as part of the keyring data
rather than requiring that the software processing it calculate the ID for
every single key it finds in a keyring in case it's the required one.  At the
moment PKCS #15 is actually a better PGP keyring format than the native PGP
one because it stores PGP 2/OpenPGP IDs that you can use to index the keys in
a file without having to process the entire keyring and manually calculate the
ID for every key in it just to find a particular key.

Peter.

---

From: Bryan Ford <[email-masked]>
Date: Sat, 9 Apr 2016 12:55:42 -0300

> At present, we use the key fingerprint as the authentication string. The mining protection he's suggesting isn't a bad thing. My raised eyebrow comes from conflating the two. We need to have a "DB…

I agree that “fingerprints” used purely as internal DB-handles or indexes are a separate purpose from “fingerprints” presented to users and displayed on business cards and websites, and it may well be worth treating them separately.

With that in mind, here’s one terminology suggestion.  Previous versions of PGP by default tend to use small, weak somethings it calls “key IDs” as the normal user-presentation form of fingerprints.  We know that encouraging users to depend on key IDs for anything - or even to understand that “Key ID” collisions are possible and eminently mineable - and hence we know that “Key IDs” of this kind need to die.  

But if we consider “PGP tradition” terminology to be that “fingerprints” are supposed to be full-length DB handles for internal use, whereas “key IDs” are something related but different for user display and consumption, we could make both of them better in V5 while preserving this terminology convention.

In particular:

- V5 “fingerprint" is just a raw SHA384 or SHA512 hash of the key material (with or without timestamp or other stuff, depending on the WG’s decision on that orthogonal issue).  This is the “DB-handle”.  It’s never expected to be presented into the user or put on business cards.

- V5 “key ID” is derived from the V5 fingerprint and shortened for presentation to the user - but shortened only to ~256 bits, not shortened to the point of insecurity like V3/V4 key IDs are.  That shortening could easily include simple Key ID mining-protection.

This would make new “Key IDs” actually safe to use for the purposes they tend to get used for, while avoiding the usage conflation with the “DB handle” purpose of fingerprints.  PGP implementations could go on displaying “key IDs” by default when listing keys, only for V5 keys these key IDs would now be long enough to provide meaningful protection.

What is the actual function from “fingerprint” to “key ID”?  Three alternatives spring to mind:

1. Truncation, from 384 or 512 bits to 256.  Trivial but offers no possibility of Key-ID mining protection.

2. Simple mining protection: Key ID is one digit representing number of leading zero hex digits in fingerprint, followed by encoded final 256 bits of fingerprint.  Basically PHB’s suggestion.

3. Memory-hardened mining protection: use fingerprint as nonce for a small Argon2 run, then SHA384 or SHA512 hash the output of that, and finally encode as in option 2 above (one-digit representing number of leading zeros followed by encoding of last 256 bits).

All of these alternatives allow the “fingerprint” to be used as an internal DB-handle with no added complexity or inefficiency, while adding only a rather small amount of complexity and cost purely to the conversion from internal-purposed “fingerprint” to user-presentation-oriented “key ID”.  If the WG doesn’t perceive the added protection of memory-hardening in option 3 is worth the costs, then option 2 would seem at least to me to have pretty much negligible cost.

Bryan

---

From: Bryan Ford <[email-masked]>
Date: Sat, 9 Apr 2016 12:58:15 -0300

> need to decide how to compute and structure the fingerprint.

+1.  I love user-friendly interactive key-verification mechanisms for the use-cases they apply to, and worked on them as part of my PhD for example.  But until they’re so usable and ubiquitously-deployed that no one needs to put their PGP key fingerprint on their business card or web site anymore, we still need to care at least a little bit about fingerprints that can be put on business cards and websites.

B

---

From: Vincent Breitmoser <[email-masked]>
Date: Sun, 10 Apr 2016 23:14:49 +0200

Bryan Ford([email-masked])@Sat, Apr 09, 2016 at 12:55:42PM -0300:
> - V5 “key ID” is derived from the V5 fingerprint and shortened for presentation
> to the user - but shortened only to ~256 bits, not shortened to the point of
> insecurity like V3/V4 key IDs are.  That shortening could easily include simple
> Key ID mining-protection.

This was discussed before, but bringing this up again because I see you
saying 256 bit fingerprint for comparison like it's the natural
conclusion:

It's perfectly valid to go for stronger bitsizes in algorithms with the
argument that computers get better at crunching numbers all the time -
but humans don't. We should not increase the bit size here just because
that feels like the thing to do while revising a standard

Instead, we need to carefully consider the requirements for a string
used for authentication by manual comparison, the result of which I'm
pretty sure will be nowhere near 32 bytes of data.

 - V

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 11 Apr 2016 09:04:20 -0300

Fingerprints are used for two purposes.

1) To define a trust anchor.
2) To verify that a purported trust anchor is correct

Only the first of these requires the ability to enter the fingerprint
at a keyboard. The most efficient way that is compliant with existing
keyboards etc. is Base32. While not all keyboards have latin
characters, there is an effective limit on the number of keys, screen
real estate etc.

The second requires only the ability to compare the fingerprints. Here
the PGP word scheme shows a more efficient approach, using an alphabet
of effectively 256 glyphs that are phonetically distinct words.

But we need not stop at 256 code points. We could just as easily use
Base65536 or Base1048576 alphabets. Comparing pictures, words,
whatever.

Words are my favorite as they allow keys and/or fingerprints to be
encoded in messages. Lets say that our alphabet has a restriction that
the words have to be 4 letters or more.

A 128 bit key in base65536 requires 8 words, lets say these are boat
syringe lawnmower noise suitcase horse advice loaf. You can make up a
cryptic phrase to encode the key steganographically.

Fix the boat, use a syringe. The lawnmower noise is bad. etc.

The downside to word dictionaries is that they are language specific.
Images are better.

For the Mesh, I plan to eventually use vocabularies of curated images.
Get a bunch of 256 volunteers, give them the task of curating
collections of 256 picture themes each to find pictures that are
visually distinct.

I have more here:

https://datatracker.ietf.org/doc/draft-hallambaker-udf/

---

From: Vincent Breitmoser <[email-masked]>
Date: Mon, 11 Apr 2016 14:29:26 +0200

> of effectively 256 glyphs that are phonetically distinct words.

I'm quite in agreement with most of your thoughts here, however the
actual *representation* of this data (baseN, words, pictures, ...) was
agreed to be out of scope for the standard, if I'm not mistaken.

I do think though that the *length* of this data is a technical detail
that should not be left up to best practices.

 - V

---

From: Derek Atkins <[email-masked]>
Date: Mon, 11 Apr 2016 12:10:45 -0400

> that there is no need to somehow also convey the creation timestamp.

Wait, is this for the authentication string or the DB lookup handle?  I
still think we're conflating the two.  And for an authentication string
I including the additional data is just fine.

When someone hands me the business card I would expect it to contain the
authentication string, not the DB Handle.  But there is also additional
data available to me, like the userID (email address).

>From a user process point of view I would expect to lookup the key using
the userid and then use the authentication string from the business card
to make sure I got the right key.

At this point, including the metadata (timestamp) in the authentication
string is fine, because I have the public key certificate including all
the metadata.

If you're doing automated key transfer then you could just use the
Database Lookup Handle.  But again, at that point where you have the
handle and need to look up the key, the only question is whether you
have a database or just raw material.

>    Werner

-derek

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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 11 Apr 2016 20:13:20 -0400

On Mon 2016-04-11 08:04:20 -0400, Phillip Hallam-Baker wrote:
> at a keyboard. .

For my own practice, i've found that i do better verification by typing
in a fingerprint than by reading and checking in my own head.

if i'm asked to compare two fingerprints that are displayed to me on
different media (say, a computer screen and a business card), i observe
that i simply lose patience and focus before the comparison is
completed and tend to opt toward "yeah that's good enough".

But with the other approach, it's pretty easy to power through the "data
entry" task of transcribing the (relatively short) fingerprint from the
business card to the computer, and just let the machine do the
fingerprint comparison.

I have no idea how prevalent these particular cognitive biases are with
other humans, but i'd be reluctant to say that we should expect people
to always do verification of fingerprints without data entry.

> The most efficient way that is compliant with existing

Here is a link to base32 encoding for folks who aren't used to it:

  https://tools.ietf.org/html/rfc4648#section-6

a base32-encoded bitstream should be marginally smaller than (it should
be 80% as long as) the same bitstream encoded as hex.  A 40-bit field
would consume 8 octets in base32, but 10 octets in hex.

i would really like us to make a clear recommendation for a common
textual interchange format for these identifiers; i'm not convinced
that it's actually out-of-scope for 4880bis.

     --dkg

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 16 Apr 2016 16:16:25 -0400

As a general rule, humans remember 7+/-2 items in short term (working) memory.

So trying to compare two 25 character, base32 fingerprints is going to
be error prone. This is why I use character grouping in my UDF
proposal to group them into blocks of 5. But even that isn't ideal by
any means.

So yes, I agree with DKG that typing a fingerprint in (or cut n'
paste) is often the way to go.

As I see it, Base32 is the 'mandatory to implement' option. We need it
because that is the only thing that is going to work in circumstances
for which we currently use PGP fingerprints (and all the other stuff I
want to support).

But I don't have to be limited to just that when I am connecting my
new watch to my personal set of connected devices. For that, a better
choice would be a vocabulary of words or images. If the vocabulary has
65536 entries, I can encode the entire fingerprint in 6-8 images
(depending on whether I choose to use work hardening).

This is an option of course. But it is a very good option to have for
two reasons. First it allows us to make crypto easier. But secondly,
it gives a lot of people who want to help make crypto happen a
tangible thing that they can work on that will help.

I see compiling the dictionary as a campaign tool opportunity.
Something that groups like the EFF, ACLU and such could kick off.
Sanitizing a vocabulary of 64K English words would be a task a student
could complete in a week. With that proof point and the tools, we
would then create dictionaries for the next 32 most used languages
through crowd sourcing.

Every person who worked on the project would be invested in the
success. They would be advocates for the system they invested in.

The other approach I am rather taken by is a modification of the
'synchronized LED blink' scheme someone proposed here. It turns out
there is quite a bit of prior art.

Say you are in a data center. There is a red light on every CPU card,
they all blink in synchronization. This tells you two things, First
that they are all connected to the same clock with negligible skew and
secondly that they are all controlled under the same root of trust.
Isn't that exactly the sort of information that it would be great to
have in a data center?

The modification that I would like to see is that instead of just
turning an LED on or off, it can be used to broadcast additional data
or the root of trust data at a higher bitrate.

The upshot of that is that when I hold a camera up to the LED, such as
the one on my smartphone, it can capture data from the device at a
rate of 10-Baud or so. (30fps camera / 2 - overhead). Its not exactly
fast but I can get a machine readout of the trust root fingerprint and
the machine fingerprint in half a minute (125 bits each)

I don't know about you, but I for one would have loved being able to
find out what a device was and what was controlling it in 30 seconds
without unplugging it back when I did big data center stuff.

Again, it is an option, it is not the mandatory to implement. But the
point of having a standard is to choose something that works for both
the narrow case and can be extended to new and interesting uses as
well.