Re: [Endymail] Hashes of key as addresses

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

On Thu, Sep 4, 2014 at 9:29 AM, Michael Kjörling <[e-mail]> wrote:
> On 29 Aug 2014 09:37 -0400, from [e-mail] (Phillip Hallam-Baker):
>> 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]
>>>
>>> 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.
>
> Fair enough, but how would you resolve such a hash without
> connectivity?

How does the email get sent at all without connectivity?

Now clearly there are circumstances in which a client has a
compromised email only connection. But these are actually pretty rare
these days and I don't see a problem with saying that we can't do end
to end directly in that situation.

In my current implementation the email can be composed offline as
normal. The S/MIME enhancement takes place in an outbound SMTP proxy
as the mail is being sent.


> We know that traffic analysis is being done on a massive scale, and
> have good reason to believe that encrypted traffic is routinely and
> specifically targeted for storage for possible later analysis.

Which is why we need STARTTLS even in an endymail world.



>> 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.
>
> Far from everyone does, even today. [1] Should the protocol be
> designed to essentially require such?

Well it is working right now without any QR code implemtnation.


>> There does not need to be a central repository. There does not even
>> need to be global connectivity.
>
> Then how would you propose to validate a hash, or given a hash, send a
> message to it, without some sort of connectivity to some sort of hash
> repository?

The repository does not need to be unified or global. Right now the
so-called 'repository' consists of posting files to a web site of the
email address holder's choice.


I do object when people insert pejorative terms like 'global
repository' into a scheme.

I think it very likely that a global repository will emerge naturally
because it is convenient to do and I expect 95% of keys to end up in
it. But I do not expect it to ever be complete.