[aerogear-dev] Crypto questions

Bruno Oliveira bruno at abstractj.org
Wed Oct 30 10:23:54 EDT 2013


Aloha!

> Christos Vasilakis <mailto:cvasilak at gmail.com>
> October 29, 2013 12:26 PM
> Hi there,
>
> during the development of security bits in iOS I had come up with some
> questions which I will appreciate your input. In particular:
>
> a) As described here [1] a passphrase is asked to be entered by the
> user and then we use PBKDF to generate the encryption keys which we
> will then encrypt user's data. The problem I see with this approach,
> is that if the user decides to change his passphrase we need to
> re-encrypt users’ data with the new key. 
I think this feature must come on the next releases, if you check some
well recognized applications like 1password
(http://help.agilebits.com/1Password3/change_master_password.html) is
completely trick to do it. Into this release use let's make it simple:

1- User provides and confirm her password for encryption
2- Data is encrypted
> A possible solution is to generate a random _symmetric key_ and then
> use PBKDF (with user’s passphrase) to encrypt that _symmetric key_. In
> that we stay independent of the user’s passphrase change. 
I'm not sure if I got it right, but if an attacker is able to break the
passphrase would be just a matter of recover that key to decrypt the
data, looks like we just added encryption over encryption.
> It can also help in scenarios where a separate PBKDF key can be used
> to encrypt the _symmetric key_ , generated by security questions (in
> case the user forgets his passphrase).
Security questions should never happen for local encryption, for this
reason the server must be added on the next release. SafeSlinger for
example adds the concept of Sling keys
(https://www.cylab.cmu.edu/safeslinger/instructions-main.html) so you
are able to decrypt data with previous keys, but I really want to stick
with simple, if for some reason user forgot his password for this very
initial release we won't recover her password.
>
> b) From my understanding, data can be decrypted on server since a
> shared secret is used (produced by Diffie-Hellman)? 
The server won't be added into this release, but answering the question.
Server should never be able to decrypt user's data, if something closer
to this was added into our spec (by me or anyone else) that's wrong.
> How can this be avoided? During my search came up with a 'Split
> Server-Side Keys’ concept described here [2]. Basically two keys are
> generated one half resides on the client (generated by PBKDF) one on
> the server (random). The server can’t decrypt without possession of
> the client key and vice versa. Looked interesting
That's what https://issues.jboss.org/browse/AGSEC-136 stands for. We
should never expose sensitive user's data for the server.

Let me know if I got your questions correctly.
>
> Thanks,
> Christos
>
>
> [1] http://tinyurl.com/p65tjhv
> [2] https://gist.github.com/cvasilak/200180a133e4eb2573ac
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-- 
abstractj


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131030/64dfd665/attachment.bin 


More information about the aerogear-dev mailing list