Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google's end-to-end key distribution proposal

code.google.com

Post reply on HN
Print view View original

21–30 of 95 posts

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

#21

Post by tubelite »

jpgvm wrote: post #11
bostik wrote: post #10

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

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

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.

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

#22

Post by blueskin_ »

tubelite wrote: post #21
jpgvm wrote: post #11

Earlier quoted context omitted.

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

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.

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

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

#24

Post by blueskin_ »

IgorPartola wrote: post #5
kleiba wrote: post #3

Earlier quoted context omitted.

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.

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

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

#25

Post by blueskin_ »

blueking wrote: post #23

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

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.

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

#26

Post by blueking »

blueskin_ wrote: post #25
blueking wrote: post #23

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

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…

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.

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

#27

Post by vidarh »

Semaphor wrote: post #20

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.

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

#28

Post by tubelite »

blueskin_ wrote: post #22
tubelite wrote: post #21

Earlier quoted context omitted.

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.

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

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.

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

#29

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

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

#30

Post by blueskin_ »

blueking wrote: post #26
blueskin_ wrote: post #25

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…

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.

I wasn't implying any trust in google on my part (I didn't trust them even before PRISM, but that shut the door on the chance of my ever trusting them again), and chances are this will never progress beyond a draft spec, but there isn't any real way to implement something like this without doing so. the NSA would find the block chain of this helpful, yes, but it isn't data they don't already have unless it is somehow extended to non-email messaging as well.
Post reply on HN