Live data from Hacker News

Google's end-to-end key distribution proposal

code.google.com

61–70 of 95 posts

Re: Google's end-to-end key distribution proposal

#61
post #50

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…

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?

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.

Re: Google's end-to-end key distribution proposal

#62
post #27

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…

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.

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

Re: Google's end-to-end key distribution proposal

#64
post #39

Earlier quoted context omitted.

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?

You would not be able to stop individual users from doing so, but you could potentially make it legally untenable for commercial/corporate operators. 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.

The whole point is ease of key exchange. Of course if you don't want any hint of your email details out in the world you shouldn't use it.

Re: Google's end-to-end key distribution proposal

#66
post #60

Earlier quoted context omitted.

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…

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)

This is part of End-To-End[1]. There's no way for their code to see the email contents, even locally in the browser. That's the whole point, in fact.

[1] https://code.google.com/p/end-to-end/

Re: Google's end-to-end key distribution proposal

#67
post #60

Earlier quoted context omitted.

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)

This is part of End-To-End[1]. There's no way for their code to see the email contents, even locally in the browser. That's the whole point, in fact. [1] https://code.google.com/p/end-to-end/

But isn't keyword-based advertising their only revenue source from non-"Apps for Business" accounts?

Re: Google's end-to-end key distribution proposal

#68
post #60

Earlier quoted context omitted.

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)

This is part of End-To-End[1]. There's no way for their code to see the email contents, even locally in the browser. That's the whole point, in fact. [1] https://code.google.com/p/end-to-end/

If you can see your emails on your Android device and Google is admin on your device, why do you say that it is impossible for them to read your emails? I don't mean that they could read them in the cloud but if they can read them locally on your Android device and for example they could send a message back to Google saying "I think this guy should get ads for a new router".... but of course they could do much worst (they could send whole messages back for example).

Re: Google's end-to-end key distribution proposal

#69
post #59
post #58

Earlier quoted context omitted.

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.

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 f…

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

Re: Google's end-to-end key distribution proposal

#70

Earlier quoted context omitted.

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…

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

I've met plenty of non-profit privacy activists who share Mike's pessimism about web of trust authentication.
Post reply on HN