Google's end-to-end key distribution proposal

https://code.google.com/p/end-to-end/wiki/KeyDistribution

261 92 12 years ago

code.google.com

IgorPartola2• 12 years ago

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? 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• 12 years ago

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.

XorNot• 12 years ago

That's what key revocation is about though: its an assumption that the WoT will get things wrong, but that we'll be able to retroactively undo some problems.

Conversely, it is why anonymity is an orthogonal goal for non-realtime communications.

IgorPartola2• 12 years ago

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_9• 12 years ago

Solvable by only ever issuing marginal trust (technically, if enough people get social engineered in, that still causes a problem, but that's a lot harder than a single person.

Trusting above marginal level should be reserved for very few people if any at all. I don't have anyone with full trust.

mike_hearn• 12 years ago

Your server is already publishing a public key - in the certificate. "Humans" at the CA verified it.

What you're really arguing for is some army of volunteer CAs to do it (this is the WoT model summed up). However verifying identities is not fun, takes knowledge and skill to defend your private keys, and in the absence of payment will attract only a tiny number of uber-geeks who think the word "party" is a reasonable word to describe a bulk ID verification ceremony ;) This is why the WoT is a bust and nobody developing new crypto systems cares about it anymore.

phkahler• 12 years ago

> This is why the WoT is a bust and nobody developing new crypto systems cares about it anymore.

I think the real reason nobody cares about it is because it gives you actual privacy. There is no way to exploit it commercially. All they could get is that data went "from here to there" with no idea what was in it. Not even Google could target ads with that.

rbobby• 12 years ago

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• 12 years ago

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?

phaer• 12 years ago

Yes the could, but it would at least cost them more resources which could matter at the scale most spammers work.

lifeisstillgood3• 12 years ago

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)

blueskin_9• 12 years ago

It'd probably become like SPF/DKIM - somewhat spammy companies who still have a genuine mailing list and will still opt you out if you ask (or even click 'Spam' in gmail etc via FBLs) will go to the effort to implement it, but random viagra spam being pumped out by botnets likely won't.

bostik2• 12 years ago

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• 12 years ago

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. :)

bostik2• 12 years ago

Ah, so that's why.

The term "Merkle tree" was familiar, but I didn't know what it was used for. (Read: never had reason to look it up.) Now I do.

Thank you. :)

tubelite2• 12 years ago

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_9• 12 years ago

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.

sarciszewski• 12 years ago

Hash then compress. (Or hash then truncate.)

fryguy• 12 years ago

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

michaelt• 12 years ago

  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_9• 12 years ago

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).

Semaphor2• 12 years ago

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

vidarh6• 12 years ago

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.

nomailing• 12 years ago

One more reason to implement the append-only log using blockchain technology. Seems like a good fit. I don't think privacy laws can be applied to a blockchain, but probably that is still unclear. For example, if I post my email address in a Bitcoin transaction, can I then force every user to delete their blockchain?

tomp2• 12 years ago

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.

meskio• 12 years ago

This is not worst than the key infrastructure right now, that not only reveals all the email address but their relationships.

thefreeman• 12 years ago

Can you elaborate on how the gossip mechanism reveals who you are communicating with?

From my understanding (which obviously could be off) what is sent with the gossip protocol is a verification of the entire key directory, similar to a git commit hash.

blueking9• 12 years ago

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

blueskin_9• 12 years ago

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.

blueking9• 12 years ago

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.

yutah3• 12 years ago

Google would not give up the ability to see email content... maybe they would analyze them locally on your phone instead of on a remote server (that might even save them from buying a few server too)

jfindley• 12 years ago

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.

bjornsing2• 12 years ago

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

magicalist4• 12 years ago

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

bjornsing2• 12 years ago

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.

higherpurpose• 12 years ago

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/

jonttaylor2• 12 years ago

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/

Soyuz• 12 years ago

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?

jonttaylor2• 12 years ago

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.

peterwwillis• 12 years ago

"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.

kennu2• 12 years ago

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• 12 years ago

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?

kennu2• 12 years ago

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?

contingencies• 12 years ago

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....

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.

SudoNick• 12 years ago

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.

Google's end-to-end key distribution proposal

Related Stories