4 ms·

Sure. Public/private keys for all users. Private key encrypted with a user's pin that is not known to us, and encrypted private key stored on servers. All of th

Sure. Public/private keys for all users. Private key encrypted with a user's pin that is not known to us, and encrypted private key stored on servers. All of this happens at the user's browser. We don't don't have access to your private keys, so, can't decrypt posts on the server.

beza1e1 15y ago
Doesn't that lead to a lot of overhead? If i have a hundred friends and i broadcast a message, then the message must be encrypted a hundred times with each friend's public key.
- privachi123 15y ago
  Yes, you are right there is overhead involved. In our tests, however, the delays didn't end up being too high for users with up to 125 friends (even on mobile devices). Delays will be worse beyond that, but will have ways around it if it comes down to it. Will be a good problem to have :)
michaelchisari 15y ago
Until a user provides their pin, and you decrypt their private key. Then you have the private key, although you may choose not to remember it. This doesn't solve the privacy issues such as with Facebook and other centralized servers, where you distrust the host as much as hackers or other users. EDIT: You may want to read this: http://wiki.appleseedproject.org/doku.php?id=future:encryption:client-side_encryption http://wiki.appleseedproject.org/doku.php?id=future:encrypti...
- privachi123 15y ago
  The decryption of private key happens in the user's browser, not on the server. We still don't know user's decrypted private key on the server. Thanks for the link.
  - michaelchisari 15y ago
    So you're doing the data encryption/decryption through a browser plugin, then? Is the source available? If it occurs in the browser, why are the (encrypted) private keys stored on the server? Why not store them in the browser?
  - privachi123 15y ago
    Nope. No plugin involved. Encryption/decryption carried out in JS. Storing it on a particular browser will limit user's access to the service from any other browser :)
    - michaelchisari 15y ago
      Hmmm, again, that assumes trust of the host serving up the Javascript. I know it may seem nit-picky, but it's not a concern that can be easily dismissed.
      - yid 15y ago
        At some point, you're going to have to trust software that someone else has written. I understand that you see Appleseed as the solution, but it really doesn't solve the problem of 99% of users downloading a binary that they blindly run. When you're at that level, a Javascript file is as transparent (if not more) than an Appleseed binary.
        michaelchisari 15y ago
        I think you're missing the point, though. When you have a centralized site, one of the problems that we've seen with Facebook is the issue of being "host-safe". There's too much financial incentive to do something with that data, and no other viable business model has been proposed. A site which promises to solve Facebook's privacy issues can't make those promises while serving up Javascript decryption code. It's too easy for the host to inject a simple line of code which pulls the pin number and sends it back to the host, which can then decrypt everything. They could do this with a single page load, and then never do it again, so that you would have to catch the malfeasance that one time. It's a case of misplaced trust, simply because things are "encrypted". They could get around this via an open source browser plugin so that it can be peer-reviewed, or (more desirably) the functionality can be integrated into browsers via the HTML5 spec. There's no such thing as an Appleseed binary, btw, it's written in a scripted language.
drdaeman 15y ago
Nate Lawson on in-browser JS crypto: http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ http://rdist.root.org/2010/11/29/final-post-on-javascript-cr... For example, you (or any powerful-enough third party,as you don't even have HTTPS), could anytime throw in any malicious JS code to get whatever data he wants. And, given that PIN is limited to 4 digits, it's not a protection at all, just a snake oil.

beza1e1 15y ago

Doesn't that lead to a lot of overhead? If i have a hundred friends and i broadcast a message, then the message must be encrypted a hundred times with each friend's public key.

privachi123 15y ago
Yes, you are right there is overhead involved. In our tests, however, the delays didn't end up being too high for users with up to 125 friends (even on mobile devices). Delays will be worse beyond that, but will have ways around it if it comes down to it. Will be a good problem to have :)

michaelchisari 15y ago

Until a user provides their pin, and you decrypt their private key. Then you have the private key, although you may choose not to remember it. This doesn't solve the privacy issues such as with Facebook and other centralized servers, where you distrust the host as much as hackers or other users. EDIT: You may want to read this: http://wiki.appleseedproject.org/doku.php?id=future:encryption:client-side_encryption http://wiki.appleseedproject.org/doku.php?id=future:encrypti...

privachi123 15y ago
The decryption of private key happens in the user's browser, not on the server. We still don't know user's decrypted private key on the server. Thanks for the link.
- michaelchisari 15y ago
  So you're doing the data encryption/decryption through a browser plugin, then? Is the source available? If it occurs in the browser, why are the (encrypted) private keys stored on the server? Why not store them in the browser?
- privachi123 15y ago
  Nope. No plugin involved. Encryption/decryption carried out in JS. Storing it on a particular browser will limit user's access to the service from any other browser :)
  - michaelchisari 15y ago
    Hmmm, again, that assumes trust of the host serving up the Javascript. I know it may seem nit-picky, but it's not a concern that can be easily dismissed.
    - yid 15y ago
      At some point, you're going to have to trust software that someone else has written. I understand that you see Appleseed as the solution, but it really doesn't solve the problem of 99% of users downloading a binary that they blindly run. When you're at that level, a Javascript file is as transparent (if not more) than an Appleseed binary.
      - michaelchisari 15y ago
        I think you're missing the point, though. When you have a centralized site, one of the problems that we've seen with Facebook is the issue of being "host-safe". There's too much financial incentive to do something with that data, and no other viable business model has been proposed. A site which promises to solve Facebook's privacy issues can't make those promises while serving up Javascript decryption code. It's too easy for the host to inject a simple line of code which pulls the pin number and sends it back to the host, which can then decrypt everything. They could do this with a single page load, and then never do it again, so that you would have to catch the malfeasance that one time. It's a case of misplaced trust, simply because things are "encrypted". They could get around this via an open source browser plugin so that it can be peer-reviewed, or (more desirably) the functionality can be integrated into browsers via the HTML5 spec. There's no such thing as an Appleseed binary, btw, it's written in a scripted language.

drdaeman 15y ago

Nate Lawson on in-browser JS crypto: http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ http://rdist.root.org/2010/11/29/final-post-on-javascript-cr... For example, you (or any powerful-enough third party,as you don't even have HTTPS), could anytime throw in any malicious JS code to get whatever data he wants. And, given that PIN is limited to 4 digits, it's not a protection at all, just a snake oil.