10 ms·

Google's end-to-end key distribution proposal

IgorPartola 12y 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 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 12y 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 12y 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.
  - IgorPartola 12y 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_ 12y ago
      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.
  - blueskin_ 12y 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 12y 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 12y 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.
    - schoen 12y ago
      I've met plenty of non-profit privacy activists who share Mike's pessimism about web of trust authentication.
deleted 12y ago
[deleted]
rbobby 12y 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 12y 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 12y ago
    Yes the could, but it would at least cost them more resources which could matter at the scale most spammers work.
    - laggyluke 12y ago
      AFAIK most spammers use botnets, so they don't really care about resources - it's not their resources to begin with.
  - lifeisstillgood 12y 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)
    - vidarh 12y ago
      They'd just keep creating new keys, and use a botnet to exchange seemingly valid e-mails with itself and a trickle of seemingly legit e-mails (buy access to a few small legit mailing lists to make sure their botnet isn't a total island). It's not clear to me that this won't make it possible for spammers to manufacture/buy sufficient "trust" to put themselves in a better situation than they're in today.
bostik 12y 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 12y 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. :)
  - bostik 12y 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. :)
  - tubelite 12y 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_ 12y ago
      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...
blueskin_ 12y 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 12y ago
  Hash then compress. (Or hash then truncate.)
- fryguy 12y ago
  Presumably the 140 characters is more like a git revision number than reversible compression.
michaelt 12y 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_ 12y 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).
Semaphor 12y 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
- vidarh 12y 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.
  - tomp 12y 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.
    - malka 12y ago
      in EU, you can say at any point to a company 'delete every piece of personal information about me that you have', and email is considered an personal information. Even if you gave consent, you can withdraw consent at any point in time.
      - tomp 12y ago
        So, basically, I can tell my bank/credit agency/hospital "please forget that I got a mortgage/defaulted/tested positive for HIV"? Doesn't that sound rather risky?
blueking 12y ago
The last people in the world you want managing your keys. Why don't you just send them directly to the NSA ?
- blueskin_ 12y 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.
  - blueking 12y 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.
    - blueskin_ 12y ago
      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.
      - blueking 12y ago
jfindley 12y 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.
bjornsing 12y ago
Slightly worrying to see the word "checksum" used to refer to a one-way cryptographic hash function...
- magicalist 12y ago
  Huh? The only mention of a checksum also acknowledges it's possible to brute-force reverse it, aka not one-way.
  - bjornsing 12y 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 12y 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/ https://pond.imperialviolet.org/
jonttaylor 12y 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/ http://senditonthenet.com/
- Soyuz 12y 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?
  - jonttaylor 12y 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 12y 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.
kennu 12y 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 12y 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?
  - kennu 12y 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?
- deleted 12y ago
  [deleted]
contingencies 12y 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.html 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 12y 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.

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 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 12y 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 12y 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.
- IgorPartola 12y 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_ 12y ago
    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.
- blueskin_ 12y 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 12y 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 12y 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.
  - schoen 12y ago
    I've met plenty of non-profit privacy activists who share Mike's pessimism about web of trust authentication.

deleted 12y ago

[deleted]

rbobby 12y 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 12y 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 12y ago
  Yes the could, but it would at least cost them more resources which could matter at the scale most spammers work.
  - laggyluke 12y ago
    AFAIK most spammers use botnets, so they don't really care about resources - it's not their resources to begin with.
- lifeisstillgood 12y 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)
  - vidarh 12y ago
    They'd just keep creating new keys, and use a botnet to exchange seemingly valid e-mails with itself and a trickle of seemingly legit e-mails (buy access to a few small legit mailing lists to make sure their botnet isn't a total island). It's not clear to me that this won't make it possible for spammers to manufacture/buy sufficient "trust" to put themselves in a better situation than they're in today.

bostik 12y 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 12y 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. :)
- bostik 12y 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. :)
- tubelite 12y 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_ 12y ago
    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...

blueskin_ 12y 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 12y ago
Hash then compress. (Or hash then truncate.)
fryguy 12y ago
Presumably the 140 characters is more like a git revision number than reversible compression.

michaelt 12y 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_ 12y 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).

Semaphor 12y 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

vidarh 12y 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.
- tomp 12y 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.
  - malka 12y ago
    in EU, you can say at any point to a company 'delete every piece of personal information about me that you have', and email is considered an personal information. Even if you gave consent, you can withdraw consent at any point in time.
    - tomp 12y ago
      So, basically, I can tell my bank/credit agency/hospital "please forget that I got a mortgage/defaulted/tested positive for HIV"? Doesn't that sound rather risky?

blueking 12y ago

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

blueskin_ 12y 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.
- blueking 12y 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.
  - blueskin_ 12y ago
    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.
    - blueking 12y ago

jfindley 12y 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.

bjornsing 12y ago

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

magicalist 12y ago
Huh? The only mention of a checksum also acknowledges it's possible to brute-force reverse it, aka not one-way.
- bjornsing 12y 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 12y 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/ https://pond.imperialviolet.org/

jonttaylor 12y 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/ http://senditonthenet.com/

Soyuz 12y 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?
- jonttaylor 12y 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 12y 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.

kennu 12y 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 12y 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?
- kennu 12y 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?
deleted 12y ago
[deleted]

contingencies 12y 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.html 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 12y 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.