Ahoy answers inline.
> <mailto:bruno@abstractj.org>> wrote:No problem I will create a branch at aerogear.org for it and add how to
>
>
>
> 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/aerogear.crypto.js#L21
> (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.
properly generate the keys.
>TBH the idea of those diagrams was to suggest some scenarios to discuss
> 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.
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)
>> -Matthias
> >
>
> > * 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.
>
>
--
abstractj
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev