Re: [openpgp] Mining protection in fingerprint schemes

[Phillip Hallam-Baker <[e-mail]>]

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.