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.

Improve this question
$\endgroup$
1
  • $\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
    Commented Jan 17, 2018 at 12:04

1 Answer 1

Reset to default
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.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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