3 ms·

From looking at "upload.js" you are using AES in counter mode. var aesCtr = new aesjs.ModeOfOperation.ctr(encryptionKeyBytes, new aesjs.Counter(-1)); Plea

From looking at "upload.js" you are using AES in counter mode. var aesCtr = new aesjs.ModeOfOperation.ctr(encryptionKeyBytes, new aesjs.Counter(-1)); Please use https://github.com/bitwiseshiftleft/sjcl https://github.com/bitwiseshiftleft/sjcl which supports a very high-level sjcl.encrypt(passphrase, plaintext) API and has been audited, instead of using crypto primitives. One specific issue is you are only encrypting, not authenticating, so if the servers are compromised someone could send back a fake plaintext.

jamescostian 10y ago
Re authentication: the site uses HTTPS, and doesn't HTTPS provide authentication that you are connected to the right server, receiving only data from that server (assuming the server and it's contents aren't compromised)? Or are you referring to another type of authentication
- Nullabillity 10y ago
  > assuming the server and it's contents aren't compromised That's the assumption that file authentication would remove. Well, assuming that the server isn't also sending a backdoored client..
deathanatos 10y ago
> if the servers are compromised someone could send back a fake plaintext. The server is sending the JS responsible for doing the encryption, no? If the server is compromised, all bets are off. You must trust this third party with your (unencrypted) data, unless you verify the JavaScript each and every time.
NoFile 10y ago
AES-CTR is indeed what's currently being used. SJCL is definitely an option and we will compare the two to see if there are any large advantages to switching over, thank you for your suggestion. The reason to why the content isn't being authenticated is due to memory issues in the browser, but we're close to adding a solution for that as well. Overall the encryption feature is currently in BETA and there will be large amount of improvements before it's finalized.

jamescostian 10y ago

Re authentication: the site uses HTTPS, and doesn't HTTPS provide authentication that you are connected to the right server, receiving only data from that server (assuming the server and it's contents aren't compromised)? Or are you referring to another type of authentication

Nullabillity 10y ago
> assuming the server and it's contents aren't compromised That's the assumption that file authentication would remove. Well, assuming that the server isn't also sending a backdoored client..

deathanatos 10y ago

> if the servers are compromised someone could send back a fake plaintext. The server is sending the JS responsible for doing the encryption, no? If the server is compromised, all bets are off. You must trust this third party with your (unencrypted) data, unless you verify the JavaScript each and every time.

NoFile 10y ago

AES-CTR is indeed what's currently being used. SJCL is definitely an option and we will compare the two to see if there are any large advantages to switching over, thank you for your suggestion. The reason to why the content isn't being authenticated is due to memory issues in the browser, but we're close to adding a solution for that as well. Overall the encryption feature is currently in BETA and there will be large amount of improvements before it's finalized.