I have an idea for an app that might be useful (though if it isn't, I've still learned in the process, which is what matters).
There are a bunch of encrypted pastebin web apps out there (e.g. defuse.ca/pastebin.htm) that perform the encryption/decryption on the client using JavaScript. So end-to-end encryption is achieved, UNLESS someone hacks the server and modifies the JavaScript so that future users who connect get modified JavaScript code that leaks their unencrypted password back to the hacker.
My idea is the user should interact with a standalone client app instead of a browser app to remove the JavaScript vulnerability.
- User downloads client standalone app. Some security is provided during download / install because: a. Client app is digitally signed b. Downloads happen from an https server c. SHA hashes are available for downloaded files d. Source code for client app is available
- User launches app and selects "new paste". He see a big text box.
- User types/pastes text and clicks "Submit". User is prompted for a password and enters it.
- Client app CSPRNG generates 128-bit salt S.
- Slow derivation function takes in password and S and derives 256-bit key K and 128-bit initialization vector IV.
- Aes encrypt performed (128 bit block size, 256 bit key, CBC mode, PKCS7 padding) using plaintext, K, and IV to produce cyphertext C.
- Client app calls server (rest call to https uri), passing it S and C.
- Server stores S and C in a database row (S is primary key).
- Server tells client the data is stored. Client tells user "data saved" and presents S to the user as the unique paste identifier.
- User makes a note of S (text file on his computer, e-mail to himself, etc... it does not have to be kept secret). Password must be kept secret.
- Later, the user launches the client app again.
- He chooses "open existing paste". He inputs S and selects find.
- Client app asks the server to find a paste matching S (rest call to https uri). If it does, it returns the encrypted text.
- If paste is found, client app prompts user for decryption password. He types it in.
- Slow derivation function takes in password and S and derives 256-bit key K and 128-bit initialization vector IV.
- Aes decrypt performed (128 bit block size, 256 bit key, CBC mode, PKCS7 padding) using plaintext, K, and IV to produce plainText.
- Client app puts plaintext in the box. User may alter it and re-encrypt or close it and make a new paste (go back to step 2).
Notes:
- Several users may view the same paste if: a. They agree in advance on a password or the password is communicated from user 1 to user 2 after he makes a paste, AND b. The user who makes the paste shares S with other users (this may be shared insecurely).
Questions:
- What security vulnerabilities does this setup have and how might it be improved?
- Am I missing anything vital in terms of the user experience?
- Re: Step 17. I read that you should never use the same salt twice. It would be annoying for the identifier of the paste (S) to change with each modification / reencryption (if multiple users are accessing the same paste they would need to recommunicate the new S each time an update/reencryption is made), but is it unavoidable to do this if I don't want to sacrifice security?
Thanks in advance!