8:09 a.m.
Ahoy answers inline.
Matthias Wessendorf wrote:
On Thu, Oct 10, 2013 at 1:58 PM, Bruno Oliveira <bruno(a)abstractj.org
<mailto:bruno@abstractj.org>> wrote:
Matthias Wessendorf wrote:
> Thanks for putting together the gist; I did read several times over
> it, and I guess it mostly makes sense :-)
>
> However I do have a few (minor?) questions:
>
> ===JavaScript:===
>
> * key: generatedKey,
>
> where does the generate key come from ? Is that a key that, as shown
> in the diagram, comes from "the server"?
Which kind of section are we talking about? Basically I skipped it
into
the documentation because developers are able to provide their own but
you can see an example here:
https://github.com/aerogear/aerogear-js/blob/master/tests/unit/crypto/aer...
(that was used only for unit test purposes to guess the output)
If you think that's not enough I'm fine providing an example about how
to properly generate the key.
Not sure we need it on the gist, but I think it does not hurt.
No problem I will
create a branch at aerogear.org for it and add how to
properly generate the keys.
I understand (like in the test) that we locally generate the key, but
the first diagram (for instance) was a bit confusing. Now I understand
it is an option, e.g. to request a key from a server: so it is really
up to the developer (e.g. request a remote key), not up to our library.
TBH the
idea of those diagrams was to suggest some scenarios to discuss
with the team (to guarantee that I'm not suggesting something insane or
impossible). We can do both or not, either way is possible to elaborate.
Scenario 1 - Let's think for a bit about the current situation, if the
key is locally generated by the app and the device is stolen would be
easy to an attacker to decrypt that data right? So that's the reason why
that must be a remote request as you mentioned, we must be able to
revoke those keys.
Scenario 2- The client generate it's own key and the server also do the
same. When you authorize client key on the server we are able establish
a key agreement between the two parties to start the encryption tango.
Makes sense?
Our library "just" uses any given key, or am I wrong ?
Our library can accept any given key for local encryption, but I would
do not encourage. What all the client libraries must do to while we
don't have a server?
1- Generate the keys
2- Encrypt the data
3. Think about how to properly retrieve the key for
encryption/decryption. For example: for Android I know we can do it with
KeyStore
http://developer.android.com/reference/java/security/KeyStore.html (but
I can be wrong)
>
> * PBKDF2: However, in the (outdated?) gist we use a function
> (AeroGearCrypto.pbkdf2()) to get access to the Pbkdf2 class;
I don't think so, once the code wasn't merge I can't make assumptions
into something that "might be" merged.
not sure what you mean.
-Matthias
--
abstractj