[Cryptography] Google E2E (was: Any opinions on keybase.io?)

[Max Kington]

On 18 Dec 2014 17:02, "Guido Witmond" <guido at witmond.nl> wrote:
>
> On 12/17/14 18:26, Tony Arcieri wrote:
> > In an E2E-like system, Johnny's computer stores the private key, not the
> > provider. The threat which would circumvent the encryption is a MitM
> > attack perpetrated by the key-directory-who-is-also-his-email-provider.
> >
> > If we want to detect this attack without Johnny having to know about
> > keys, we need a way that Johnny's agent can detect that the directory is
> > misadvertising his public key to others without forcing Johnny to go
> > through a key verification process with the people he's communicating
with.
>
> I've came up with a protocol that lets the user agents detect if their
> key-directory is MitMing them.
>
> It takes a round trip of one message each and sufficient time to
> propagate the certificates though the out-of-bound
> certificate--uniqueness-validation-service. I've called it the registry
> of dishonesty....
>
http://eccentric-authentication.org/eccentric-authentication/global_registry_of_dishonesty.html
>

I designed something similar but with a difference. A point to point MitM
which does a back to back attack is still possible and much harder to
detect. I conceived the system to work within social networks. (or if you
prefer, phone book)

> The beauty of validation service is this:
>
> The agents need to validate this MitM-status only at the moment the two
> users want to communicate. After it is clear that there is no MitM, the
> agents record that fact and remember it. The agents make sure to always
> use the proven certificate to encrypt messages to the other. There is no
> way for the key-server-annex-email-provider to MitM these two endpoints
> ever.

The tricky part here is that if you are able to discern who is making the
request for public key data then you could insert pairs of false public
keys AND ONLY to those clients you are trying to MitM. One for client A and
one for Client B.

That way your directory 'looks clean' to others. Worse still if the
subsequently negotiated session key is long lived you don't need to MitM it
all the time. You get around this by ALSO signing the messages but in my
world that was annoying because of the cycles that eats (or in my use case
the battery power that consumes) but I couldn't see a way around that. A
bit like you you want immediate detection not relying on your next session
key renegotiation to stand another chance picking it up.

The protocol I designed dealt with this attack by having the idea of
authenticated directory querying and anonymous directory querying before I
realised that actually 'anonymous' was pointless because that puts a
massive burden on the system to actually enable anonymous access.

The other component was to Co opt people to help you validate keys. So I do
the verification (much like you describe) and at negotiation time I also
(and I think this is probably where our schemes differ) I ask others to
tell me what their view of the key is. They can do this a number of ways.
Through asking the directory, or by prior knowledge or both or even copting
others into the question.

You can then build a mesh of 'viewpoints'.

That mesh is a really interesting beast. Pick other verifiers at random? Or
people you trust? Or people who might know the person already? I'm doing
*alot* of thinking about this property.

You seem to maintain a 'trust memory' a bit like I do.

The other thing was I introduced the idea that you put a 'watch' on the
public keys of people you know *and* the directory needs to publish a CT
like transparency chain. When you put a watch on you start your 'trust
memory' at that point and you add meta data to your own record when you
have your own conversations with these people.

When  you ask for someone's viewpoint on a public key. That can include the
CT chain, from when you remembered it, when you last used it and what the
trust mesh looks like.

What this does is make the global MitM directory attack (1 fake key
published to the world) easy to detect and the back to back pointed attack
hard to execute successfully. Because you have to try to back to back the
MitM attack the entire mesh and hope nobody has prior memory of the real
key.

>
> Here's the requirements for such a validation service:
>
http://eccentric-authentication.org/blog/2014/03/26/how-to-design-a-distributed-client-certificate-verification-service.html
>

Cool! Similar but different 😊

Cheers
Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20141218/d58589fa/attachment.html>