Google's end-to-end key distribution proposal
code.google.com
code.google.com
>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
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.
But personally, regardless of legality, if Google implements this with the degree of disclosure of e-mail details, I'll find another operator that isn't implementing this proposal.
In practice, no, you can't demand to be wiped out from the internal database if you creditor. You probably can prevent them from publishing a debtors' list with your name, though.
Even then, as pointed out by others, this does not preclude the user from withdrawing consent to continued use of the information.
It may or may not become a legal problem. But they really need to consider the privacy implications and have lawyers that actually know the relevant national laws throughout the EU member states to evaluate it.
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.
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.
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.
Conversely, it is why anonymity is an orthogonal goal for non-realtime communications.
Trusting above marginal level should be reserved for very few people if any at all. I don't have anyone with full trust.
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.
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.
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.
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. :)
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. :)
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...
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.
Would that work? I design and build a set of tests that extend existing OSS business app A. I post them up and ask for contributions ... Only to be accepted if tests pass.
But really the value I want is in "quality" a very hard to quantify idea.
But Test first development as a means of proving compliance is a good idea. Not sure the git chain is useful though.
https://github.com/ctfs/write-ups/tree/master/stripe-ctf3/le...
Proof of work is used to limit behavior by adding artificial cost - in hashcash they are used to make spamming more expensive, and in Bitcoin for controlling block creation.
It's not a desirable feature in a protocol if you can avoid it. In the case of coding contributions, it's easier and more reliable to have a central maintainer that accepts patches and pays out bounties.
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.
I guess with this proposal, the fact you used to go by benstillerfaggot69@verizon.net will be part of your permanent record.
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.
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/
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.
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.
Why? Couldn't spammers encrypt the mail they send to you just like everybody else?
This kind if implies a secondary directory market of ratings and rankings of the prime source (ie isASpammer, isWithinThreeHopsOnLinkedIn)
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.
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.
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.
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.
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.
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.
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.
Google is a front for US intelligence. We should give no quarter. Shun them.
Picking on Project Loon... come on, is there anything Google could do that you wouldn't immediately label as evil forefront of US intelligence?
Here is more on loon and look further up for links to the PRISM slides and documentation showing the companies involved including google were compensated financially by the NSA. The evidence is damning.
http://m.slashdot.org/story/194413
Look the bottom line here is these guys betrayed us. They are traitors, and we need to cut them out of our future.
From the linked Slashdot article - Google patented Loon-related technology, describing it "as just the ticket for those well-to-do enough to pay a tiered-pricing premium to get faster internet access while attending concerts, conferences, air shows, music festivals, and sporting events where a facility's overtaxed Wi-Fi simply won't do."
Picking on this is like saying that Elon Musk is an evil liar, because if he really cared about good of humanity and electric transport for the masses he surely wouldn't start with an superexpensive car for ultra rich, and then move to expensive car for moderatly-rich. Obviously, the whole argument about "Roadster bankrolling Model S bankrolling $35k Sedan" is just a bunch of lies trying to hide how evil he is.
That's basically what I'm reading from your argument.
You know, altruism involves money, and quite often the best way to do something good is to make it profitable.
> Look the bottom line here is these guys betrayed us. They are traitors, and we need to cut them out of our future.
If so, then long, long before Google you need to get rid of GoDaddy, Amazon, Facebook, Microsoft, Apple, BMW, General Motors, General Electric, Coca Cola, Nestle, Walmart, every other mom and pop store and pretty much 90% of other companies who betrayed us in many more ways, heavily documented and not alleged. Seriously, saying that Google Is Bad is nothing but a signalling game around here.
"Don't be evil... to our shareholders."
> It's all about data collection to spew more adverts at people.
The way they do this is the single most ethical way of doing advertisements. Non-intrusive and trying to predict what you actually need. They're pursuing the ultimate goal of good advertising, i.e. connecting your needs to the best way to satisfy them, but hell, they're evil.
We can discuss side effects and externalities of their data collection, but that's a completely different thing than assuming malice.
http://www.washingtonpost.com/wp-srv/special/politics/prism-...
http://gizmodo.com/confirmed-nsa-paid-google-microsoft-other...
They are lying through their teeth. As you should know skj, being a google employee.
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.
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/
1) True.
2) Consistent with statements made by Google.
3) Quickly mitigated by Google when it began encrypting traffic between data centers.
What has happened here is google has got scared. Because without trusting users all their business models fall apart. So they are lying. Its that simple.
Which is why it could never happen without it being well known inside Google.