2

I'm making a chrome app that does client side encryption of user messages. There is no server in my architecture. The encrypted text messages are saved as files in the user's Google Drive. I'm using forge javascript library to encrypt the messages. I want the user's password to be used for encryption and decryption, without saving it anywhere.

Currently I have the salt and IV hardcoded into the javascript code. But that means it's available to anyone who installs the chrome app. Is it better to generate a random IV and salt for every message, and save it in the user's Google Drive along with the encrypted messages? Or is it good enough to have it hardcoded as a js global? Is there a more secure way of doing this?

syonip
  • 143
  • 4
  • 1
    Here's a related topic about the salt/IV hard-coded (which will cause it to be static for every encryption): http://security.stackexchange.com/questions/6058/is-real-salt-the-same-as-initialization-vectors – iAdjunct Jan 01 '16 at 00:56

1 Answers1

1

In every protocol I've seen, the IV and/or salt is not considered secret, and is stored with the ciphertext. It is usually important to use a unique IV/salt for each message, though. (It is often not necessary for them to be unpredictable— just not reused.) However, each mode's requirements might be a little different.

Wim Lewis
  • 271
  • 1
  • 3
  • Thanks, so it's better to generate random values and store them with the messages. Any suggestions on how to store the values with the data? Can I just save the message+IV+salt all in the same text file? Or is there a benefit to putting them in separate files? – syonip Jan 01 '16 at 16:31