[Cryptography] Google E2E (was: Any opinions on keybase.io?)
bascule at gmail.com
Wed Dec 17 12:26:26 EST 2014
On Wed, Dec 17, 2014 at 3:31 AM, Ralf Senderek <crypto at senderek.ie> wrote:
> Without Johnny controlling (at least part of) the encryption key there is
> no assurance of security for Johnny and that's why it cannot happen to
> him transparently.
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.
On Wed, Dec 17, 2014 at 7:53 AM, Paul Hoffman <paul.hoffman at vpnc.org> wrote:
> Yep, and AFAICT, it is equally terrible to keybase.io. (More or less
> depending on whether you trust Google and Yahoo...)
I agree it would be bad if we had to trust Google or Yahoo, but in this
capacity they're not acting much different from an SKS keyserver. The only
differences would be we select which keyserver to use to obtain Johnny's
public key based on Johnny's email address, and Johnny has to authenticate
so his agent can manage his public key automatically on his behalf.
> Google proposed a CT-like transparency protocol which would help users
> identify if their directory misadvertized their keys:
> That doesn't help Johnny encrypt his personal communications. It's good
> stuff, but orthogonal to this thread.
Okay, new thread created!
A MitM attack is the only failure mode of this system. Until it happens,
Johnny doesn't have to concern himself with the encryption.
When it happens, the system (or rather, Johnny's agent auditing public logs
and gossiping via encrypted email messages) tries to detect it and inform
Johnny . Whether this is useful information to Johnny remains to be seen...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cryptography