Google's end-to-end key distribution proposal
code.google.com
Google's end-to-end key distribution proposal
1–10 of 95 posts
Re: Google's end-to-end key distribution proposal
#2Interesting. 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.
Re: Google's end-to-end key distribution proposal
#3Interesting. 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…
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.
Re: Google's end-to-end key distribution proposal
#4Interesting. 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…
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.
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.
Re: Google's end-to-end key distribution proposal
#5Interesting. 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…
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 am now in the WoT and can remove pub.pem.
Re: Google's end-to-end key distribution proposal
#6[deleted]
Re: Google's end-to-end key distribution proposal
#7I 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.
Re: Google's end-to-end key distribution proposal
#8I 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.
> 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?
Re: Google's end-to-end key distribution proposal
#9I 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.
> 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?
Yes the could, but it would at least cost them more resources which could matter at the scale most spammers work.
Re: Google's end-to-end key distribution proposal
#10Reading 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.