[aerogear-dev] AeroGear Crypto API - Draft 0. Your brain is required
Matthias Wessendorf
matzew at apache.org
Thu Oct 10 08:26:06 EDT 2013
On Thu, Oct 10, 2013 at 1:58 PM, Bruno Oliveira <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.
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.
Our library "just" uses any given key, or am I wrong ?
> >
> > Java
> >
> > * CryptoBox: It is used for different algorithms (GCM and ECC), like a
> > "ToolBox" / "ToolChain", right ?
> Once there are several tools named "ToolBox, ToolChain" outside there I
> will avoid comparisons. CryptoBox is the class responsible to accept a
> single key or a key pair and encrypt/decrypt the data.
>
Ah! Ok, I think now it makes sense. I think the name of the class was
misleading (to me)
> >
> > * 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.
> > I can't see that in the code - there a direct usage of the Pbkdf2
> > class is present.
> Until we get that code merged, I think is reasonable to keep it as is.
>
that is fine
> >
> > Now, wondering about the different 'access' mechanisms
> > (AeroGearCrypto.pbkdf2() vs. CryptoBox), does it make sense (honestly
> > not sure) to add the 'PBKDF2' to the "CryptoBox" as well ?
> I don't think so, because they are used for different purposes:
>
> CryptoBox - Accept a key or a key pair for symmetric/asymetric encryption
> PBKDF2 - For passwords as we discussed
>
yeah, now it is more clear to me, that the "CryptoBox" is not really like a
"ToolBox" for different alogrythms
-Matthias
> >
> >
> > @iOS
> >
> > we had a kick off meeting early this week, and now trying to see how
> > we move on. A few infos are available in this forked gist:
> >
> > https://gist.github.com/matzew/7cdf1831c55e3d656477
> >
> > More to follow....
>
> Let me know if something is not clear.
>
> --
> 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/09a97414/attachment-0001.html
More information about the aerogear-dev
mailing list