3 ms·

For (1), if the user has to install software on their client, then the entire point of webmail has been bypassed. I disagree that reducing the security wouldn'

For (1), if the user has to install software on their client, then the entire point of webmail has been bypassed. I disagree that reducing the security wouldn't render end-to-end encryption useless. Remember that the purpose of end-to-end encryption is to protect the user against malicious service providers. If you want to store a user's data on a Google server, but ensure that Google is unable to read it for XX years, then you need to take a lot of security precautions. Forgetting any of them would allow the user's data to be compromised. > Nobody should be able to run a search on every word > I've written to anyone in the past ten years but me. If this is your goal, then your only realistic option is to install an open-source mail client on its own dedicated machine, set up GPG, generate your GPG keys on that machine, and don't let it do anything but talk SMTP+POP3 with your mail provider. Read all your email in plaintext. This sounds paranoid, but it's actually the absolute minimum required if you want to ensure that your emails are safe from a malicious entity with corporate- or government-sized budgets. Further precautions might include removing the HDD and keeping the machine airgapped with email transfer performed by CD-ROM. Then you get to go down the physical-security rabbit hole to prevent someone with a warrant from bugging your keyboard. The reason for all these precautions is that a malicious provider could save all of the encrypted emails you send/receive over the years. They only need to grab your keys once. Or you could, you know, relax a bit and figure that storing personal email on Google/Microsoft/Yahoo/Apple servers is probably OK.

napoleond 14y ago
It's not webmail as we know it, that much is true. In an age of mobile and tablet prevalence, that's less important than it used to be. It would still be possible to send emails from a browser session (doesn't require exchanging private keys, it just wouldn't be signed... in other words, a "stopgap" sort of ability) and if you are using a trusted SSL connection (I know that's an if, but still pointing it out) you could have synchronous communications in a browser that were still being saved in an encrypted format. The purpose of this is actually not to prevent a concerted attack on your communications--there are too many physical/social vectors in that scenario for encryption to even matter. The purpose is to prevent your personal correspondence from being indexed anywhere outside of your complete control, and to be transmitted in a way that prevents the elementary eavesdropping possible today. It should also make the sort of subpoena requests performed by "regular" law enforcement impossible. Most departments don't have the resources to crack a sufficiently complicated passphrase. So what I should have said is nobody should be able to run a search on every word hundreds of millions of people have written in the past ten years which they thought was private correspondence. And the system I am describing really would put an end to that ability. (NOTE: I'm not saying I think anyone at Google can do that. Maybe the NSA, but there's no proof of that either. My only point is that it's very technologically feasible right now and it shouldn't be.) EDIT: By the way, for people who do know what they're doing and are willing to go through the extra steps, a system like the one I describe here (and am building) is still a net win--instead of your ultra-secure setup being limited to communicating with your ultra-secure friends, there would be a middle road for general communications with less tech-savvy associates.
- jmillikin 14y ago
  > nobody should be able to run a search on every word > hundreds of millions of people have written in the past > ten years which they thought was private correspondence. If it's possible for your provider to compromise your system and take your keys, then they can run a search on everything you've sent through their routers. If they can compromise one system, they can automate it and compromise ~100% of typical consumer machines, and then have access to all of their email. The steps I described do not stop a concerted attack. They are merely the minimum required to prevent blanket surveillance of all email accounts managed by any given provider. If someone does less than what I described (and I'm sure I didn't get everything), then sending encrypted email is just wasting their own time.
  - napoleond 14y ago
    Forgive me, but I don't understand how what you're describing is remotely possible. Cracking a single bcrypted passphrase should take an average time on the order of years. NSA and their ilk can maybe reduce that significantly, but they still won't be cracking an entire system any time soon, even if it's only 1,000 user accounts. We must be talking past each other. I promise I'm not trying to be obtuse--could you please try again?
    - jmillikin 14y ago
      A malicious provider wouldn't have to brute-force the key; they could compromise your browser to steal the key and install a keylogger to take your password. Browser exploits aren't expensive, and zero-days are discovered semi-regularly. A sufficiently well-capitalized provider could even pay researchers to find new browser exploits, so they don't have to depend on scavenging them out of feral malware samples. This would probably work only once or twice, but would give that provider the ability to read any encrypted payloads that they have recorded.
      - napoleond 14y ago
        Ahh yes, we did somehow manage to misunderstand each other completely. There is no scenario in my system in which the browser sees any keys or passphrases, encrypted or otherwise--that would only happen in a signed standalone client program capable of running native code. (The browser does see a password in the potential "send-only" scenario I described earlier, but that's a separate secret unrelated to the PGP key.) Yes, it would be possible to maliciously alter that code and redistribute it, but it would be difficult since the source would be open and anyone could verify the hash. At that point, it's probably easier to just infect the host computer with a keylogger some other way (and wait for the user to lose their key so that they need to use their passphrase, then intercept 2 factor auth somehow), but that's like the deus ex machina of computer security (and still not at all automatable at large scale as far as I can see, especially due to 2FA).

napoleond 14y ago

It's not webmail as we know it, that much is true. In an age of mobile and tablet prevalence, that's less important than it used to be. It would still be possible to send emails from a browser session (doesn't require exchanging private keys, it just wouldn't be signed... in other words, a "stopgap" sort of ability) and if you are using a trusted SSL connection (I know that's an if, but still pointing it out) you could have synchronous communications in a browser that were still being saved in an encrypted format. The purpose of this is actually not to prevent a concerted attack on your communications--there are too many physical/social vectors in that scenario for encryption to even matter. The purpose is to prevent your personal correspondence from being indexed anywhere outside of your complete control, and to be transmitted in a way that prevents the elementary eavesdropping possible today. It should also make the sort of subpoena requests performed by "regular" law enforcement impossible. Most departments don't have the resources to crack a sufficiently complicated passphrase. So what I should have said is nobody should be able to run a search on every word hundreds of millions of people have written in the past ten years which they thought was private correspondence. And the system I am describing really would put an end to that ability. (NOTE: I'm not saying I think anyone at Google can do that. Maybe the NSA, but there's no proof of that either. My only point is that it's very technologically feasible right now and it shouldn't be.) EDIT: By the way, for people who do know what they're doing and are willing to go through the extra steps, a system like the one I describe here (and am building) is still a net win--instead of your ultra-secure setup being limited to communicating with your ultra-secure friends, there would be a middle road for general communications with less tech-savvy associates.

jmillikin 14y ago
> nobody should be able to run a search on every word > hundreds of millions of people have written in the past > ten years which they thought was private correspondence. If it's possible for your provider to compromise your system and take your keys, then they can run a search on everything you've sent through their routers. If they can compromise one system, they can automate it and compromise ~100% of typical consumer machines, and then have access to all of their email. The steps I described do not stop a concerted attack. They are merely the minimum required to prevent blanket surveillance of all email accounts managed by any given provider. If someone does less than what I described (and I'm sure I didn't get everything), then sending encrypted email is just wasting their own time.
- napoleond 14y ago
  Forgive me, but I don't understand how what you're describing is remotely possible. Cracking a single bcrypted passphrase should take an average time on the order of years. NSA and their ilk can maybe reduce that significantly, but they still won't be cracking an entire system any time soon, even if it's only 1,000 user accounts. We must be talking past each other. I promise I'm not trying to be obtuse--could you please try again?
  - jmillikin 14y ago
    A malicious provider wouldn't have to brute-force the key; they could compromise your browser to steal the key and install a keylogger to take your password. Browser exploits aren't expensive, and zero-days are discovered semi-regularly. A sufficiently well-capitalized provider could even pay researchers to find new browser exploits, so they don't have to depend on scavenging them out of feral malware samples. This would probably work only once or twice, but would give that provider the ability to read any encrypted payloads that they have recorded.
    - napoleond 14y ago
      Ahh yes, we did somehow manage to misunderstand each other completely. There is no scenario in my system in which the browser sees any keys or passphrases, encrypted or otherwise--that would only happen in a signed standalone client program capable of running native code. (The browser does see a password in the potential "send-only" scenario I described earlier, but that's a separate secret unrelated to the PGP key.) Yes, it would be possible to maliciously alter that code and redistribute it, but it would be difficult since the source would be open and anyone could verify the hash. At that point, it's probably easier to just infect the host computer with a keylogger some other way (and wait for the user to lose their key so that they need to use their passphrase, then intercept 2 factor auth somehow), but that's like the deus ex machina of computer security (and still not at all automatable at large scale as far as I can see, especially due to 2FA).