<br><br>On Wednesday, November 6, 2013, Bruno Oliveira wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Corinne Krych wrote:<br>
> Hello Bruno,<br>
><br>
> 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].<br>
> 1. What do you think of this practise?<br>
Assuming that Alice will send the IV and salt to Bob again to decrypt,<br>
is the best practice, speaking about the interaction between<br>
client/server. This is how ag-simple-push does with the IV.<br>
<br>
But thinking about our focus to this release (local encryption only):<br>
<br>
1. User inputs the passphrase<br>
2. Our lib generates the key based on random IV, salt and passphrase<br>
3. User add a bunch records and the app will encrypt it<br>
4. User wants to check his twitter password and enter the passphrase again.<br>
<br>
Into this situation if the IV, salt is always random to create a new<br>
key, how could you decrypt the data previously encrypted?</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div><br></div><div>If you have encrypted the twitter password and then added to the encrypted twitter password an additional header with salt and iv, you can decrypt. More secure but more storage space. And in this scenario salt and iv storage is taken care by framework.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> That's the<br>
reason why **only** to this scenario, it IV, salt needs to be stored.<br>
<br>
> 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?<br>
I think Summers' suggestion is a good idea, but consensus is a thing. So<br>
what the team thinks is the best to both platforms, I'm fine.<br>
> Should the encryption API take care of storing them?<br>
Not sure, from my POV the knowledge about the storage per platform is<br>
not the responsibility of the crypto API. Otherwise we will end up with<br>
something bloated and with the lack of focus, but is just my opinion.</blockquote><div><br></div><div>Right as always let's hear others views </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
By encryption API I understand aerogear-crypto-java, aerogear-js-crypto<br>
and aerogear-ios-crypto.<br>
> Thanks for your answers, much appreciated.<br>
mp, feel free to ask</blockquote><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--<br>
abstractj<br>
<br>
<br>
</blockquote>