[Cryptography] The names in "the mesh"

[Phillip Hallam-Baker]

On Sun, Jul 12, 2015 at 8:20 PM, Christian Huitema <huitema at huitema.net>
wrote:

> Philip,
>
>
>
> Your proposed use of names derived from cryptographic keys reminds me a
> lot of the work with did several years ago with PNRP. The principle was the
> same, pick a master key and use a hash of that master key as a node’s
> identity. In our case, it was a key to an entry in a P2P mesh. Leaving
> aside the specific details of the application, we got lots of feedback from
> our use of identifiers of form <hash>+<string>, very similar to:
>
>
>
>     mmm:MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ:alice at cryptomesh.org
>
>
>
> The main issue is that the hashes are very unwieldy. They cannot be
> visually verified by the user. An attacker can generate an alternate key
> whose hash looks “close enough” to the real thing, and then use MITM attack
> to substitute that when the key is sent from Alice to Bob. Bob performs a
> visual check, is fooled, and then the communication between Bob and Alice
> can be intercepted.
>

I think it is important to separate use of hashes in the human space and
below.

Last week I rewrote my entire crypto layer that I use on top of .NET using
fingerprints as the key identification system. Every X.509v3 cert uses the
fingerprint as the key identifier for both subject key identifiers and
authority, the fingerprint is used as the label on the key store and so on.
This has allowed be to remove about 1000 lines of code that were just there
to find keys.


For users, the only operation they are expected to do is compare two
fingerprints for equality. And usually they are just checking their own
fingerprint which should not change.

The medium term objective is to get rid of the fingerprint in base32
encoding and use something more easily recognized by a human. For example
base65536 encoding with words or images as the symbols. Let us say we could
curate a database of such images and store them on a server in a Merkle
tree form. We can now generate pictographic representations of the
fingerprint. So it should be easy to do the verification on a watch or the
like.


We explored using a “compressed hash” for verification purposes, which we
> dubbed “call sign.” The idea was to hash “
> MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ:alice at cryptomesh.org” plus some “salt”,
> choosing the salt so the hash ends with a large number of zeros. Let Z be
> that number. We would then build the call sign from the first N bits of the
> hash, and publish it as a short Base32 string. The strength of the
> verification is “N+Z”. For example, N=50 and Z=32 results in a 82 bit
> strong password, and a 10 character string.
>

Interesting.


The point of the small string is that it can be spelled over the phone, or
> copied from a card, without being too unwieldy.
>

What I was playing about with was actually similar. To generate my profile,
I was running the profile generator lots of times and looking for keys with
the strings 'phill', 'hallam', 'phb', etc in the profile. Some folk have
done the same with bitcoin handles.

Now for in person key validation, I am thinking that these days any process
is likely to involve QRCodes and smartphones. But that is a separate
problem...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150713/8ceff3a7/attachment.html>