4:01 p.m.
Checking my thoughts (and hopefully spurring some discussion)
A key (and thus salt) is unique per user.
A IV is unique per encrypted message.
In an key pair, the public key is transmitted to your recipients. The
private key is kept by the user.
With a symmetric key, both parties have the key or know how to generate
the key.
The same IV has to be present for a message to be reliably encrypted and
decrypted.
Now some questions:
How is a PBKDF2 key transmitted so a message can be decrypted?
In the case of client server how should the IV be generated/transmitted?
4:24 p.m.
Answers inline.
Summers Pittman wrote:
Checking my thoughts (and hopefully spurring some discussion)
A key (and thus salt) is unique per user.
A IV is unique per encrypted message.
Key into our scenario is a composition of
salt, IV, passphrase unique
per user.
Not by message.
In an key pair, the public key is transmitted to your recipients. The
private key is kept by the user.
With a symmetric key, both parties have the key or know how to generate
the key.
The same IV has to be present for a message to be reliably encrypted and
decrypted.
Correct.
Now some questions:
How is a PBKDF2 key transmitted so a message can be decrypted?
For this release we
don't have key exchange with the server and make use
of symmetric encryption to client/server is not the ideal. But let's
suppose you really want to do it:
1. Alice will generate the IV, salt and input the password
2. Alice sends the IV and salt to Bob
3. Bob receives the IV and salt and call Alice saying "WTF lady, how
could I decrypt it?"
4. Alice answers the phone call and says "hey, my password is: pineapple"
Now both parties know how to decrypt the message. Into this release we
are laying the groundwork for the key exchange with the server on the
next release, this is what KeyPair stands for.
In the case of client server how should the IV be
generated/transmitted?
IV can be a public information.
Let me know if you have more questions.
--
abstractj
5:04 p.m.
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?
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? Should the encryption API take care of storing them?
Thanks for your answers, much appreciated.
++
Corinne
[1]
http://crypto.stackexchange.com/questions/5440/can-i-use-my-random-iv-for...
[2] https://github.com/rnapier/RNCryptor/blob/master/RNCryptor/RNEncryptor.m#...
[3]
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-Crypto-API...
On Nov 6, 2013, at 4:24 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Answers inline.
Summers Pittman wrote:
> Checking my thoughts (and hopefully spurring some discussion)
>
> A key (and thus salt) is unique per user.
> A IV is unique per encrypted message.
Key into our scenario is a composition of salt, IV, passphrase unique
per user.
Not by message.
> In an key pair, the public key is transmitted to your recipients. The
> private key is kept by the user.
> With a symmetric key, both parties have the key or know how to generate
> the key.
> The same IV has to be present for a message to be reliably encrypted and
> decrypted.
Correct.
> Now some questions:
>
> How is a PBKDF2 key transmitted so a message can be decrypted?
For this release we don't have key exchange with the server and make use
of symmetric encryption to client/server is not the ideal. But let's
suppose you really want to do it:
1. Alice will generate the IV, salt and input the password
2. Alice sends the IV and salt to Bob
3. Bob receives the IV and salt and call Alice saying "WTF lady, how
could I decrypt it?"
4. Alice answers the phone call and says "hey, my password is: pineapple"
Now both parties know how to decrypt the message. Into this release we
are laying the groundwork for the key exchange with the server on the
next release, this is what KeyPair stands for.
> In the case of client server how should the IV be generated/transmitted?
IV can be a public information.
Let me know if you have more questions.
--
abstractj
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
5:59 p.m.
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
8:35 p.m.
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
9:13 p.m.
I'm not following you, could you please elaborate more? Are you
considering to have an IV, salt per record?
Corinne Krych wrote:
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.
--
abstractj
9:28 p.m.
I see 2 options:
- the one you suggested, you encrypt all data with the same iv, salt + passphrase. The app
stores globally iv+salt
- or you encrypt each password (in the case of our demo app) with different IV+salt. You
need to store salt+iv locally (in a header) within the encrypted stream. To decrypt, you
need first to read the header, exact salt+iv.
Second option is less efficient, but more secure because there is more randomness.
The granularity could be the responsibility of the app developer who can decide when to
change the IV+salt.
See some similar idea with code here:
https://github.com/rnapier/RNCryptor/blob/master/RNCryptor/RNEncryptor.m#...
++
Corinne
On Nov 6, 2013, at 9:13 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
I'm not following you, could you please elaborate more? Are you
considering to have an IV, salt per record?
Corinne Krych wrote:
> 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.
--
abstractj
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:23 p.m.
Corinne Krych wrote:
I see 2 options:
- the one you suggested, you encrypt all data with the same iv, salt + passphrase. The
app stores globally iv+salt
That's the goal
- or you encrypt each password (in the case of our demo app) with
different IV+salt. You need to store salt+iv locally (in a header) within the encrypted
stream. To decrypt, you need first to read the header, exact salt+iv.
Second option is less efficient, but more secure because there is more randomness.
I must say that I will disappoint you for 2 reasons:
1. You are not adding any extra level of security here, once the IV,
salt is still predictable and stored on the local storage. You are just
delaying the attacker, for some hours and trying to solve the absence of
the server here, but if you guys think that this will add some security,
that's ok.
2. For this release we still don't have an API to query encrypted data.
So unless someone has already implemented it I can't see how to do it,
targeting our release date.
The granularity could be the responsibility of the app developer who
can decide when to change the IV+salt.
Let people choose with previous skills about
encryption never work.
That's the reason why we are trying to make it simple here.
See some similar idea with code here:
https://github.com/rnapier/RNCryptor/blob/master/RNCryptor/RNEncryptor.m#...
As
far as I know RNCryptor is just a wrapper, so I doubt they are
storing bazillion records + IV, salts. If some app does it locally, it's
just the false sense of security in my opinion.
--
abstractj
10:45 p.m.
On Nov 6, 2013, at 10:23 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Corinne Krych wrote:
> I see 2 options:
> - the one you suggested, you encrypt all data with the same iv, salt + passphrase.
The app stores globally iv+salt
That's the goal
> - or you encrypt each password (in the case of our demo app) with different IV+salt.
You need to store salt+iv locally (in a header) within the encrypted stream. To decrypt,
you need first to read the header, exact salt+iv.
>
> Second option is less efficient, but more secure because there is more randomness.
I must say that I will disappoint you for 2 reasons:
You're not disappointing me. I like to explore solutions in details.
1. You are not adding any extra level of security here, once the IV,
salt is still predictable and stored on the local storage. You are just
delaying the attacker, for some hours and trying to solve the absence of
the server here, but if you guys think that this will add some security,
that's ok.
2. For this release we still don't have an API to query encrypted data.
Definitively not for this release.
So unless someone has already implemented it I can't see how to
do it,
targeting our release date.
> The granularity could be the responsibility of the app developer who can decide when
to change the IV+salt.
Let people choose with previous skills about encryption never work.
That's the reason why we are trying to make it simple here.
> See some similar idea with code here:
> https://github.com/rnapier/RNCryptor/blob/master/RNCryptor/RNEncryptor.m#...
As far as I know RNCryptor is just a wrapper, so I doubt they are
storing bazillion records + IV, salts. If some app does it locally, it's
just the false sense of security in my opinion.
--
abstractj
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:45 p.m.
Sure, feel free to file jiras, into this way we don’t miss it to the further releases.
--
abstractj
On November 6, 2013 at 7:45:30 PM, Corinne Krych (corinnekrych(a)gmail.com) wrote:
On Nov 6, 2013, at 10:23 PM, Bruno Oliveira wrote:
>
>
> Corinne Krych wrote:
>> I see 2 options:
>> - the one you suggested, you encrypt all data with the same iv, salt +
passphrase. The app stores globally iv+salt
> That's the goal
>> - or you encrypt each password (in the case of our demo app) with different
IV+salt. You need to store salt+iv locally (in a header) within the encrypted stream. To
decrypt, you need first to read the header, exact salt+iv.
>>
>> Second option is less efficient, but more secure because there is more
randomness.
> I must say that I will disappoint you for 2 reasons:
>
You're not disappointing me. I like to explore solutions in details.
> 1. You are not adding any extra level of security here, once the IV,
> salt is still predictable and stored on the local storage. You are just
> delaying the attacker, for some hours and trying to solve the absence of
> the server here, but if you guys think that this will add some security,
> that's ok.
>
> 2. For this release we still don't have an API to query encrypted data.
Definitively not for this release.
> So unless someone has already implemented it I can't see how to do it,
> targeting our release date.
>> The granularity could be the responsibility of the app developer who can decide
when to change the IV+salt.
> Let people choose with previous skills about encryption never work.
> That's the reason why we are trying to make it simple here.
>> See some similar idea with code here:
>> https://github.com/rnapier/RNCryptor/blob/master/RNCryptor/RNEncryptor.m#...
> As far as I know RNCryptor is just a wrapper, so I doubt they are
> storing bazillion records + IV, salts. If some app does it locally, it's
> just the false sense of security in my opinion.
>
> --
> abstractj
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4078
days inactive
4078
days old
9 comments
3 participants
participants (3)
-
Bruno Oliveira -
Corinne Krych -
Summers Pittman