Corinne Krych wrote:
> Hello Bruno,
>
> Two more questions: I've read [1] that it's good pratice to change IV for each encryption. IV/salt being random and public information can be stored in the header of the encrypted message. See RNCryptor where header is added to encrypted stream with salt and IV[2].
> 1. What do you think of this practise?
Assuming that Alice will send the IV and salt to Bob again to decrypt,
is the best practice, speaking about the interaction between
client/server. This is how ag-simple-push does with the IV.

But thinking about our focus to this release (local encryption only):

1. User inputs the passphrase
2. Our lib generates the key based on random IV, salt and passphrase
3. User add a bunch records and the app will encrypt it
4. User wants to check his twitter password and enter the passphrase again.

Into this situation if the IV, salt is always random to create a new
key, how could you decrypt the data previously encrypted?

 That's the
reason why **only** to this scenario, it IV, salt needs to be stored.

> 2. Going as you suggested (one key/IV/salt per user) we don't necesseraly need the header append to encrypted stream, we could just store those information at application level as suggested by Summers [3] or maybe add them to the keystore as suggested by Christos?
I think Summers' suggestion is a good idea, but consensus is a thing. So
what the team thinks is the best to both platforms, I'm fine.
>  Should the encryption API take care of storing them?
Not sure, from my POV the knowledge about the storage per platform is
not the responsibility of the crypto API. Otherwise we will end up with
something bloated and with the lack of focus, but is just my opinion.

By encryption API I understand aerogear-crypto-java, aerogear-js-crypto
and aerogear-ios-crypto.
> Thanks for your answers, much appreciated.
mp, feel free to ask

--
abstractj