[aerogear-dev] Encrypted Data and IVs

[Corinne Krych]

On Wednesday, November 6, 2013, Bruno Oliveira wrote:

>
>
> 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?


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.



>  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.


Right as always let's hear others views

>
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131106/f910194a/attachment.html