
Google's end-to-end key distribution proposal - abdullahkhalids
https://code.google.com/p/end-to-end/wiki/KeyDistribution
======
Semaphor
The first comment by Mailpile seems to highlight the biggest problem to me:

>Hello! Bjarni from the Mailpile team here.

>This is an interesting proposal and sounds like a significant improvement
over the current centralized key-server model.

>The main quibble I have with it, is it seems there's no concern given to the
privacy of user's communications - the proposed gossip mechanism seems
designed to indiscriminately tell everyone who I am communicating with. That's
a pretty severe privacy breach if you ask me, worse even then PGP's web-of-
trust because it's real-time, current metadata about who is interacting with
whom.

>Am I misunderstanding anything here?

>\- Bjarni

~~~
vidarh
As I just posted as a comment to the proposal:

In the EU, e-mail addresses are personally identifiable information. It's not
clear that an append-only log with no expiration or means for individuals to
delete the content will even be legal in many EU countries.

~~~
tomp
What do you mean? When users sign up to a Key Registry, they are explicitly
acknowledging that their emails and public keys can be used in the way
described by the protocol. AFAIK, that's perfectly legal.

~~~
malka
in EU, you can say at any point to a company 'delete every piece of personal
information about me that you have', and email is considered an personal
information. Even if you gave consent, you can withdraw consent at any point
in time.

~~~
tomp
So, basically, I can tell my bank/credit agency/hospital "please forget that I
got a mortgage/defaulted/tested positive for HIV"? Doesn't that sound rather
risky?

~~~
desas
It's not that simple (in the UK at least), you only have to stop processing
information if "unwarranted and substantial damage or distress" is being
caused.

~~~
asuffield
Additionally, all stop processing / deletion regulations require a court
order, which will be subject to all the usual requirements of justice.

~~~
vidarh
It only takes a single successful demand before an append-only log because
untenable.

------
jfindley
I was amused to see that on neither of the links in the post does SSL work
correctly. convergence.io identifies as whispersystems and www.certificate-
transparency.org produces an ssl error on every version of openssl and browser
I have to hand (I didn't try anything with non-standard ECC curves).

That said, however, the entire end-to-end project is for me one of the most
interesting and exciting practical innovations in security in years.

------
IgorPartola
Interesting. It has bugged me for some time that if the Web of Trust was
bigger, it could grow exponentially and become universal: once someone you
personally know has entered you into the WoT, you can be trusted and can trust
others based on a number of public signatures on their public key. However,
currently the WoT is so sparse that you cannot do this.

My idea was to use the existing web TLS platform to bootstrap the WoT to a
sufficiently large level. I run my email on my own domain. Why can't I tell
the WoT (and have it trust that it is true) that my public key is XYZ by
putting it at
[https://igorpartola.com/pub.pem](https://igorpartola.com/pub.pem)? GMail
could do something similar and at least to start, we could get enough emails
validated to start having the WoT spread on its own. Then we could modify the
infrastructure to remove the public CA's and central authority entirely, by
using the WoT itself. Google's HTTPS cert would then be based on its PGP key
and be verified by humans inside the WoT.

I also think that the important part of the WoT is verifying emails/digital
identity, not government docs. I don't care if I am talking to "Bob Bobber", I
care that I am talking to bob@bobber.com. I may never have met bob@bobber.com,
but I see his/her public git repos, blog, etc. and I want to connect to them
securely.

~~~
kleiba
Let's not forget that one of the most successful attack vectors is social
engineering, that is, tricking people into trusting you and making you part of
the WoT.

~~~
IgorPartola
Sure. But if you are willing to trust some CA to issue me a HTTPS cert for my
domain, why are you not willing to trust that I serve my public key for this
domain suing this HTTPS cert to secure its transport? Oh, sure some adversary
could gain control of the web server used for this and replace my pub.pem, but
then I will notice and revoke it. And once enough people download and sign my
pub.pem, it no longer matters: I am now in the WoT and can remove pub.pem.

~~~
blueskin_
I think the issue is that a lot of people who are informed about CAs _don 't_
trust them, but we still don't have anything better that's anywhere even close
to wide adoption.

------
bostik
Reading through the spec, there is something eerily familiar with the key
directory implementation. Quoting:

 _Alice will obtain a proof from the Key Directory that demonstrates that the
data is in the permanent append-only log, and then just encrypt to it.

Within the message to send to Bob, Alice includes a super-compressed version
of the Key Directories that fits in a 140 characters (called STHs which stands
for Signed Tree Heads). This super-compressed version can be used later on by
anyone to confirm that the version of the Key Directory that Alice saw is the
same as they do_

Append-only log. Global. Hash of the log's tip state at the time of use...

Smells like a mixed blockchain/git type approach - which is a good thing. The
"super-compressed" version of the log tip sounds like git revision hash. The
append-only, globally distributed log is pretty much like a blockchain.

And it attempts to solve a really hard global problem. I like it.

~~~
jpgvm
The blockchain (as most people understand it atleast) is an implementation of
a Merkle tree. Which is why Git/Bitcoin are eerily similar - they both utilize
Merkle trees for integrity.

The real innovation in the "blockchain" was using proof of work in combination
with the Merkle tree in order to enforce a single history. Take that away and
yes, it looks alot like Git. :)

~~~
tubelite
And if you consider that a git commit is actually "proof of work" and find a
way to quantify the value of that commit (fixes issue x which was worth y
points, passes all regression tests), you would have... gitcoin.

~~~
blueskin_
Quickly, buy the .in domain name and throw a client up onto github ;)

Edit: Domain already taken; I guess after bitcoin's success people just bought
up (word)co.in for every value of word they could think of...

~~~
tubelite
I'm only half joking :) Gitcoin is much looser than bitcoin when it comes to
verifying proof of work. However, there is a (practical) sense in which it
exists. Fixes are submitted, accepted, merged, pulled until they are part of
all users' "blockchains". gitcoin is the quantization of this karma. The lack
of a hard definition of work means that it is perhaps easier to bootstrap in a
centralized ecosystem like Github. Like Quora credits for code.

In much the same way as Quora credits are used to power A2As, gitcoin would
enable you to ask J Random Coder on github for a fix and pay him in karma. The
GPL is effectively a no-freeloaders mechanism, gitcoin could be another.

------
michaelt

      The special thing about this Key Directory, is that 
      whatever is written in the directory can never be 
      modified, that is, it's impossible to modify anything from 
      there without having to bring the service down, or telling 
      to everyone that's looking about what is being modified. 
    

The MIT PGP key server has eleven different keys in my name which I created in
1997, when I was about 12 years old. Of course, I have long since lost the
private keys and e-mail addresses.

I guess with this proposal, the fact you used to go by
benstillerfaggot69@verizon.net will be part of your permanent record.

~~~
blueskin_
Unless I missed a part of it, the key is only permanently tied to the email
address - i.e. you could always say that benstillerfaggot69@verizon.net is a
different Joe Bloggs and not you (probably only plausible if you have a common
to medium rarity name though).

------
higherpurpose
My suggestion is for them to work at least another 12 months on this, before
they even begin to publicly test it on Gmail accounts. We need more privacy
quickly, but let's not rush into a protocol that could last for another 20
years, if all the major e-mail providers adopt it. We need to get this right.

I wish the DIME (former Dark Mail) protocol was out already, too, so we can
compare. There's also Adam Langley's Pond [1], but sounds like it's too
complex, and it only works over Tor. And TextSecure/Axolotl could probably be
used as a secure e-mail protocol, too, if you add a proper e-mail like
interface. I hope the team behind End-to-End is looking at all of them.

[1] - [https://pond.imperialviolet.org/](https://pond.imperialviolet.org/)

------
jonttaylor
I have been through this thought process before. The conclusion I came too was
that the implementations should be transparent, but that the user information
should not.

Basically I was not going to put up a list of everyones email addresses and
keys anywhere, and certainly not who they connect with.

The more I looked into the problem, the more I realised that the vast majority
of users would rather sacrifice security for usability. Even in my
implementation people would rather not see the "Please verify this key with
the recipient" page. They just want to get something done. I think this
proposal from google would work well so long as their base implementation
involves no additional steps beyond that of a normal email client.

My implementation uses a central key authority, however the application is
pure javascript, and the entire javascript is downloaded to the browser prior
to the user entering their email address and password. After that no more code
gets sent to the client. You can verify it wont steal your data.

I have the same problem of initial key exchange that everyone else does, but I
give the user options to verify they keys themselves. Once they have they
encrypt their own contact list (along with keys) and re-upload it. Therefore
limiting the attack vector to initial key exchange.

If anyone wants to have a look check out
[http://senditonthenet.com/](http://senditonthenet.com/)

~~~
Soyuz
Do you use Key Escrow for private key storage? How can the other receiver
decrypt the file using his browser only? Where do you store the private key?

~~~
jonttaylor
The users password acts as a symmetric key. It is never sent to the server,
but a hashed copy is sent to the server for authentication, which is then
rehashed and stored in the DB.

The users private key is AES encrypted with the password as key and sent to
the server for storage. A JSON hash of their contacts is also encrypted in the
same way and sent to the server for storage.

------
rbobby
I hope this works out. If enough of the big email vendors (gmail, outlook,
yahoo, etc.) get on board the network effect could be enough to push adoption
to a very high percentage.

Once that happens my "unencrypted" email folder would be viewed about as often
as my junk mail folder.

And then... maybe just maybe... spammers will be faced with a serious
challenge.

~~~
y0ghur7_xxx
> And then... maybe just maybe... spammers will be faced with a serious
> challenge.

Why? Couldn't spammers encrypt the mail they send to you just like everybody
else?

~~~
lifeisstillgood
Because, I think, they would have to be part of the Key Directory too, listed
under "Spammer".

This kind if implies a secondary directory market of ratings and rankings of
the prime source (ie isASpammer, isWithinThreeHopsOnLinkedIn)

~~~
vidarh
They'd just keep creating new keys, and use a botnet to exchange seemingly
valid e-mails with itself and a trickle of seemingly legit e-mails (buy access
to a few small legit mailing lists to make sure their botnet isn't a total
island). It's not clear to me that this won't make it possible for spammers to
manufacture/buy sufficient "trust" to put themselves in a better situation
than they're in today.

~~~
lifeisstillgood
Darn - I think you are right... Ah well, defeating spam is only a nice to have
from this

------
kennu
How will the Key Directories and third party Monitors verify that I'm the real
owner of my self-hosted email address user@myowndomain.com, uploading my real
public key to the directory?

~~~
pdonis
Depends on what you mean by "verify the real owner". They can verify that
whoever has control of what gets uploaded to myowndomain.com also has control
of the user@myowndomain.com email account and can prove they have the private
key corresponding to the public key that was posted. Is that what you meant?

~~~
kennu
Is that verification process described somewhere in Google's proposal? I don't
understand how it would work with third party Monitors. Would I have to prove
my identity with some email-callback or DNS/HTTP token separately to them all?

------
SudoNick
Wouldn't proper compartmentalization dictate that email providers be
explicitly eliminated from the end-to-end encryption process?

Apart from being able to inspect email and recognize that it contains content
that looks like an encrypted form of something, I think we wouldn't want them
to be explicitly informed that encryption was used, or know anything about the
encryption algorithm, or know anything about how keys were distributed, or see
any keys even public ones.

I think this would apply to the general case where someone uses an email
service that is run by another party. In the common cases of major email
providers with business models that conflict with privacy and security in
various ways, the risks would higher. Even before factoring in their being
high priority targets for hacking, government surveillance of questionable
legality, etc.

------
contingencies
TLDR is: _Distributed (as in DNS) directory with append-only entries keyed by
hash-of-email and third party replication /validation/logging._

Discussion of spam implications at [https://moderncrypto.org/mail-
archive/messaging/2014/000727....](https://moderncrypto.org/mail-
archive/messaging/2014/000727.html)

Widespread encryption _could_ be a recipe for Google (as the largest of the
proposed directories) sliding in an identity reputation scheme (eg. based on
location / communications history) and brokering it as a service.

------
blueskin_
So it seems they invented PGP keyservers with a monitoring protocol as a bag
on the side?

I've had keys on keyservers for years. The monitoring side is interesting
though.

It's also unclear how the whole directory will be compressed to 140 bytes -
iirc, the best compression algorithms reduce text by ~80-90%, so it might work
for a week or so, I guess.

~~~
fryguy
Presumably the 140 characters is more like a git revision number than
reversible compression.

------
peterwwillis
_" The model of a key server with a transparency backend is based on the
premise that a user is willing to trust the security of a centralized service,
as long as it is subject to public scrutiny, and that can be easily discovered
if it's compromised (so it is still possible to compromise the user's account,
but the user will be able to know that as soon as possible)."_

So it's a central service where we can - eventually - find out if a key
changes or is invalid, though not necessarily if anyone just breaks into the
service. An attacker can still break in and monitor authentications to gather
intel on users. Or they can automate an attack such that the keys are
compromised and the attacker gets the access they want while you're asleep at
3am.

 _" a Monitor could notify the user whenever a key is rotated, and the user
should be given a chance to revoke the key, and rotate it once again."_

Now the user needs to see this e-mail about their key getting rotated, realize
it's a compromise, issue a new rotation, and hope nothing bad happened in the
meantime.

 _" making it so hard to hide a compromised key directory, it would almost
require shutting down all internet access to the targeted victim."_

This is completely within the scope of many different types of attacks used
today, though often you only have to limit it to specific servers.

 _" The model envisioned in this document still relies on users being able to
keep their account secure (against phishing for example) and their devices
secure (against malware for example), and simply provides an easy-to-use key
discovery mechanism on top of the user's existing account. For users with
special security needs, we simply recommend they verify fingerprints manually,
and we might make that easier in the future (with video or chat for
example)."_

So it really is just a PGP keyserver. For users who care about security, do
something else to make yourselves more secure.

------
bjornsing
Slightly worrying to see the word "checksum" used to refer to a one-way
cryptographic hash function...

~~~
magicalist
Huh? The only mention of a checksum also acknowledges it's possible to brute-
force reverse it, aka not one-way.

~~~
bjornsing
A checksum is a computationally efficient way to detect _unintentional_
changes in data. But as protection against _intentional_ changes it's quite
useless. That's what cryptographic hash functions are for.

Now the proposal described using a "checksum" to tie together two halves of a
self-signature, where one half would be a an identity and the second would be
an email address, essentially. That would make it trivial to forge a second
half with another email address (but the same "checksum").

I understand that's an entirely different problem. All I'm saying is that few
cryptographers would use the word "checksum" at all, and even fewer would use
it in this context. That's what worries me slightly.

------
blueking
The last people in the world you want managing your keys. Why don't you just
send them directly to the NSA ?

~~~
blueskin_
As much as I generally distrust google with privacy when it comes to actually
handing over data, in this case it's an open protocol that has just been
drafted by google; anyone can run a server or make their own implementation.
It also never touches private keys, only public. If you want a public key to
have limited distribution, you don't put it on a keyserver, and instead only
exchange it with the people you would like to in person or over some other
verified and secure channel.

It does have a somewhat anti-privacy feature in that if I understand it
correctly, it keeps a record of messages between participants (in the sense of
a record existing _that a message was exchanged_ although not the content),
but that level of data is already accessible to NSA/GCHQ anyway.

~~~
blueking
You think google can write a proposal like this without the NSA getting
involved ? The fact that they are preserving metadata is revealing and
meaningful. Its another PR stunt.

Google can never never be trusted again. They publicly lied about PRISM, and
they got caught. These people have no business making security protocols for
us.

~~~
skj
What statement did Google make, regarding PRISM, that was a lie? And what
evidence caused them to get caught?

~~~
blueking
[http://www.cbsnews.com/news/google-ceo-larry-page-issues-
sta...](http://www.cbsnews.com/news/google-ceo-larry-page-issues-statement-on-
prism/)

[http://www.washingtonpost.com/wp-
srv/special/politics/prism-...](http://www.washingtonpost.com/wp-
srv/special/politics/prism-collection-documents/m/)

[http://gizmodo.com/confirmed-nsa-paid-google-microsoft-
other...](http://gizmodo.com/confirmed-nsa-paid-google-microsoft-others-
millions-1188615332)

They are lying through their teeth. As you should know skj, being a google
employee.

~~~
skj
What is the actual lie?

~~~
denom
More to the point, what is the truth? Google leadership post 9/11 knew what
"certifying" their communication systems meant and took the money to do it.
Whether they knew that the program was named Prism is irrelevant, in my
opinion.

~~~
skj
Google responds to legal requests for information. The whole PRISM scandal was
indicating that the NSA had some kind of direct link into the databases
themselves. This assertion is what Google denied, and still denies.

There's been a bit of a wandering definition for PRISM, from "they have NSA
software with root access to all machines!" to "they receive LEO requests for
information, which they review, and sometimes fulfill." The former is untrue,
and the latter is true.

~~~
ChrisAntaki
> The whole PRISM scandal was indicating that the NSA had some kind of direct
> link into the databases themselves.

Though, as Google and Yahoo later found out, the NSA was directly tapping
cables between their data centers [1].

[1] [http://www.wired.com/2013/10/nsa-hacked-yahoo-google-
cables/](http://www.wired.com/2013/10/nsa-hacked-yahoo-google-cables/)

~~~
skj
That appears to be several things:

1) True.

2) Consistent with statements made by Google.

3) Quickly mitigated by Google when it began encrypting traffic between data
centers.

