Re: [Endymail] Hashes of key as addresses

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

On Fri, Aug 29, 2014 at 5:11 AM, Michael Kjörling <[e-mail]> wrote:
> On 28 Aug 2014 19:23 -0400, from [e-mail] (Phillip Hallam-Baker):
>> Using hashes of keys as addresses is very powerful. There are
>> basically three types of address in such schemes:
>>
>> 1) traditional human readable
>>
>> 2) hash of key
>>
>> 3) Traditional human readable + hash of key.
>>
>>
>> So in PPE we use all three in different situations:
>>
>> 1) ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA
>>
>> 2) [e-mail]
>>
>> 3) ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA?[e-mail]
>>
>>
>> We can apply the same approach with value to other situations. Lets
>> say Alice owns example.com. We can create a strong domain name in the
>> same way:
>>
>> ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA?example.com
>
> Does this scheme not imply that everyone who wants to validate an
> address, or know to where to pass a message given an address, needs to
> either (a) query some form of central repository where all address
> (hash)es are registered, or (b) have a local cache of all valid
> address (hash)es?

No, it implies some mechanism for resolving the hashes. But that does
not need to be centralized.

Right now what the PPE proxy does is to strip out the domain component
of the email address and performs a HTTP WKS query for the
phingerprint block. So it would look up

http://example.com/.well-known/phb/ACAIEAFONPAC5AC6LFAK4ACHCEAJWAHNVPAM4ACOYPAOVAA

The dashes are removed as they have no semantic information. They are
purely for convenience.


> Whether architectured in a distributed or centralized fashion, would
> such a registry not become problematic? Lookups would be comparatively
> costly (since even though it would be possible to split the storage,
> you'd still be looking at what basically amounts to a sequential
> search through some, likely relatively large, amount of data), if this
> catches on it would soon grow very large, and imagine what spammers
> would do if they could get their hands on a copy of that database.
> Someone who is in control of such a database would have the potential
> for massive (though not necessarily total) insight into who is
> communicating with whom.

No, the system is no worse than DNS and that scales.

No sequential searches, its a hash table lookup and so extremely fast.
Should not require more than 6 lookups.

Each person's PHB is only a few KB so we are talking about 10 Tb or so
of data if everyone has a key. That is very manageable. It would need
a business model of course but so does every scheme that proposes
infrastructure.


> We know that breaches happen, even with the best of intentions (even
> the NSA can't keep their data safe from breaches, as evidenced), so it
> would appear that an architecture that creates such a valuable target
> should be discouraged.

\The infrastructure is not trusted except for service.

An attacker cannot substitute an end-entity key because the key has to
be signed by the master key that matches the hash.


> Initial mapping from a human-friendly (no matter what format) to a
> hash (no matter what format) address would also seem to present the
> problem of ensuring that you are mapping the correct human-friendly
> address. You could, given an appropriate design, after that point be
> certain that you are communicating with the _same_ person that you
> started out communicating with, but could you be certain that you are
> communicating with the _intended_ person (as opposed to someone else
> by mistake, and as opposed to a MITMer)? If the human-friendly address
> is enough to uniquely identify the recipient, then why would we need a
> hash-based address scheme at all? If it isn't, then how is Joe R.
> User, who wants to send a message securely to Alice Journalist,
> expected to pick between "Alice Journalist, ACAIEA FONPAC 5AC6LFA
> K4ACHC EAJWAHN VPAM4A COYPAO VAA" and "Alice Journalist, GJEIWO FMCPTE
> 9NM2GME X0AZZE XMDLWLF LLCP2K UHXHYM LHE", let alone between the first
> and "Alice Journalist, ACAIEA F0NPAC 5AC6LFA K4ACHC EAJWAHN VPAM4A
> COYPAO VAA"?

That is the trust problem and there are various ways to address it.

The first step though is to have a set of addresses that can be used
to specify the trust relationship explicitly. Once we have that the
trust problem is reduced to achieving the mapping.

One way that works very well is to use QR codes in an in-person
meeting. Web of Trust never worked the way PhilZ wanted. But we didn't
carry supercomputers with cameras (aka smartphones) then.


> Compare SMTP where the originating SMTP server can do preliminary
> validation (on the order of ensuring that the address is well-formed,
> the domain exists and has a MX or address record) while the receiving
> SMTP server does final address validation (local-part/hostname pair
> exists and points to a valid mailbox) in an interactive dialog between
> the servers, allowing reasonably good error reporting back to the
> originating sender without any one entity having a complete address
> registry. Since DNS is also highly distributed, no one entity even has
> a complete list of all valid domain or fully qualified host names.

Well what you are doing is proposing the simplest solution to the
problem and showing why it is inadequate.

There does not need to be a central repository. There does not even
need to be global connectivity.