0
$\begingroup$

We have a mobile client application which stores data in localstorage for offline use. The new GDPR requirements have to mandate us to encrypt the data we store in the client.

We used Stanford's sjlc.js package to encrypt the information using AES 128 before storing them in Local Storage. We did a brief performance test and it looks fine.

But the encrypted string is like below.

{"iv":"C8aBp2GjvPiZHCRtCPu+hg==","v":1,"iter":10000,"ks":128,"ts":64,"mode":"ccm","adata":"","cipher":"aes","salt":"duWxiMbE8TM=","ct":"cC4P/pMVozDpmnD/XzW2oif9GId8ZXCo7j/kP6QGlaT8C5pO09SBy6u6DneQz/AdeSQFtG9Ng05i0tASr8RcfNRYQGOFa17I7TI5xVSnd8L7322yihqxhsBbmBFSR0xesAEYmJcoIgPp1/MB+oXzm/pn0pzl0AfZNd8dTHrN+Wa9vcg107+2rVWY7K77BL1j7knRApU....................

We have to pass the whole string back to decrypt.

As you can see it contains the salt as well. Does that defeat the purpose?

I asked this same question in https://stackoverflow.com/questions/48275430/storing-encrypted-data-in-client. There was a suggestion to post it here.

$\endgroup$
  • $\begingroup$ It would have been better to ask a moderator to move your question from stackoverflow to crypto.stackexchange, rather than having two copies of the same question on two stackexchange websites. $\endgroup$ – Geoffroy Couteau Jan 17 '18 at 12:04
2
$\begingroup$

Salt and IV are public data (just like the ciphertext) and don't reveal any data about the plaintext. They are necessary to decrypt. Therefore, they don't defeat the purpose.

$\endgroup$

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.