[megawatthours]

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 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.

[deathanatos]

> 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]

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]

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]

> 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..