4 ms·

Client-side, with a passphrase. A backup could be stored on the server or in your dropbox or wherever you'd like. It would be important, as part of the onboardi

Client-side, with a passphrase. A backup could be stored on the server or in your dropbox or wherever you'd like. It would be important, as part of the onboarding process, to communicate the need to keep the key safe and what happens to your old emails should you lose it. As for using js for public key encryption, I've implemented it for a client and didn't have much trouble. There are libraries that workaround the usual problems. What have you seen out there that would cause a problem?

kniht 13y ago
If you're doing public key crypto on the client side in javascript, then the client side JS must necessarily have access to the private key (unless you have a TPM _and_ browser hooks to use it). This means that suddenly the private key is vulnerable to any XSS attacker that can inject itself into the same origin as your javascript crypto code.
- aasarava 13y ago
  Fair point. XSS likely wouldn't be a problem in the case of a desktop email client. But in the case of a Gmail or Outlook.com frontend, I can see how you would be concerned about something in the js served up by Google or MS capturing the private key and sending it to the server. That said, couldn't this be mitigated by having a strong passphrase on the private key? How hard is the wrapper to attack? Also, couldn't security researchers easily monitor the packets on this process and sound the alarm should they find that the js served up by Google or Microsoft suddenly starts sending private keys to the server?
  - kniht 13y ago
    AFAIK a strong key passphrase would be effective at protecting the private key while it's at rest (stolen laptop / hard drive). However as soon as the private key is pulled into memory for a signing or encryption operation the passphrase doesn't matter as the raw key is needed at that point. As for your second question, there are techniques that perform static and dynamic analysis on javascript to try and detect illegal flows or taint propagation (without having to resort to monitoring the outbound network traffic). See [1] and [2] if you're interested in that topic. [1] http://static.usenix.org/event/sec10/tech/full_papers/Bandhakavi.pdf http://static.usenix.org/event/sec10/tech/full_papers/Bandha... [2] http://publik.tuwien.ac.at/files/pub-inf_5310.pdf http://publik.tuwien.ac.at/files/pub-inf_5310.pdf
    - maaku 13y ago
      Also, this isn't a hypothetical attack. Basically the same setup is used for client-side bitcoin wallets, and there have been reports of thefts (stolen keys).

kniht 13y ago

If you're doing public key crypto on the client side in javascript, then the client side JS must necessarily have access to the private key (unless you have a TPM _and_ browser hooks to use it). This means that suddenly the private key is vulnerable to any XSS attacker that can inject itself into the same origin as your javascript crypto code.

aasarava 13y ago
Fair point. XSS likely wouldn't be a problem in the case of a desktop email client. But in the case of a Gmail or Outlook.com frontend, I can see how you would be concerned about something in the js served up by Google or MS capturing the private key and sending it to the server. That said, couldn't this be mitigated by having a strong passphrase on the private key? How hard is the wrapper to attack? Also, couldn't security researchers easily monitor the packets on this process and sound the alarm should they find that the js served up by Google or Microsoft suddenly starts sending private keys to the server?
- kniht 13y ago
  AFAIK a strong key passphrase would be effective at protecting the private key while it's at rest (stolen laptop / hard drive). However as soon as the private key is pulled into memory for a signing or encryption operation the passphrase doesn't matter as the raw key is needed at that point. As for your second question, there are techniques that perform static and dynamic analysis on javascript to try and detect illegal flows or taint propagation (without having to resort to monitoring the outbound network traffic). See [1] and [2] if you're interested in that topic. [1] http://static.usenix.org/event/sec10/tech/full_papers/Bandhakavi.pdf http://static.usenix.org/event/sec10/tech/full_papers/Bandha... [2] http://publik.tuwien.ac.at/files/pub-inf_5310.pdf http://publik.tuwien.ac.at/files/pub-inf_5310.pdf
  - maaku 13y ago
    Also, this isn't a hypothetical attack. Basically the same setup is used for client-side bitcoin wallets, and there have been reports of thefts (stolen keys).