2

When using Javascript online with the server, The server can provide a unique Key and Initialization vector for use in AES-CBC available in Webcrypto API. Each user has key allocated to them. The client can encrypt data and send it to the server and decrypt there. Due to potential network issues, the data is cached. I believe that to be reasonably secure as keys are accessed via authentication and nonce salts are used.

Now the new requirement arrives: to allow the user run in offline/cache mode. Which means when the user needs to encrypt sensitive data on data entry,or when he accesses sensitive data to view it, the key is required. However the server cant be reached. We need that key and only have only a password.

I see several examples on the web which often read like this SO post
or like this Javascript AES encryption post

Just how bad is that to use AES to encrypt a 16 byte secret using the users password to derive a key and a salt that is unique but presumably PREDICTABLE?

Assuming one would set the PBDK2 iterations to as large as tolerable by users perhaps 500 msec to derive key from password.

I still cant see how they used AES without a predictable salt when a device must work when offline.

Is there an Java script accessible algorithm that copes well with a short value to encrypt and only a password derived key and device unique but known Id as salt.

EDIT with goal in mind With just the users password, and offline mode in JAVAScript what can you do? I see the browser isnt ideal for cryptography :What’s wrong with in-browser cryptography? Im trying to find the currently best known approach and understand just how bad/good it is.

  • Is the only problem you're having is getting an IV for encryption? You can just use a cryptographically secure random number for the IV and store it with the encrypted text – Neil Smithline Jun 13 '16 at 22:37
  • You just answered the question Neil. I feel a little foolish for not seeing the obvious beyond the current tool in use. Generating a salt doesnt need to be secure since it is salt and single use. So the IV is indeed accessible but very random, used only once and ONLY saved after derived key has run which is slow. My main concern is now answered. Please enter as answer so i can accept. – soadyp Jun 13 '16 at 23:02
3

You can use a CSPRNG for the IV. This can be stored next to the encrypted text. The IV does not need to be kept secure, it just must be random.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.