[aerogear-dev] AeroGear Crypto API - Draft 0. Your brain is required

[Matthias Wessendorf]

On Thu, Oct 10, 2013 at 3:09 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Ahoy answers inline.
>
> Matthias Wessendorf wrote:
> >
> > On Thu, Oct 10, 2013 at 1:58 PM, Bruno Oliveira <bruno at abstractj.org
> > <mailto:bruno at 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/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.
> No problem I will create a branch at aerogear.org for it and add how to
> properly generate the keys.
>

that would be sweet!



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

makes perfectly sense, and this thread already is providing good set of
info!


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

+1


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

+1


>
> Makes sense?
>

It does!


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

thanks for the provided information!

It helped


> >
> > >
> >
> >     > * 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
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131010/fe8c1fd2/attachment.html