Re: [aerogear-dev] JavaScript Crypto

On Sep 23, 2013, at 2:01 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Sep 23, 2013, at 12:40 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Sep 20, 2013, at 10:05 AM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: >> >>> Good morning slackland, following with the plan I started a simple draft >>> for JavaScript (https://github.com/abstractj/cryptoparty-js) we have >>> several alternatives outside there the most popular are Crypto-js >>> (https://code.google.com/p/crypto-js/) and the Stanford crypto library >>> (http://crypto.stanford.edu/sjcl/). >>> >>> Before I finish the whole implementation I have some questions: >>> >>> - Currently crypto-js doesn't have support for GCM or ECC, but sjcl has. >>> That's the reason why my choice was sjcl instead of crypto-js, but if >>> you have another good alternative, let me know. >> >> +1 for sjcl if you think it offers everything we need >>> >>> - Create wrappers or not? If you read the unit tests at first glance (at >>> least for me) looks like is too much. Most part of developers are >>> looking for security by default. >> >> +1 I would like us to provide methods like encrypt or decrypt which use default values which we choose because we have researched and feel they are the best option for devs. >>> My idea is not to hide the library, but >>> provide a simple interface like: >>> >>> Crypto crypto = new Crypto; >>> ciphertext = crypto. encrypt("blah"); >>> crypto.decrypt(ciphertext); >> >> I agree with this syntax in spirit but not execution. ;) JS doesn't have types like Crypto crypto, just var crypto. I would also prefer to follow the pattern we use in the rest of AeroGear.js to allow for instantiation without the use of the `new` keyword'. You can see the source of the other modules or ping me for details. > > Now that I think about it, if this is just for encryption and decryption, I think this would look better and be more user friendly in AeroGear.core. That way, a user doesn't even have to instantiate and object, they just use our shortcut methods to call into sjcl. For example: > > AeroGear.encrypt("blah"); > AeroGear.decrypt( cipherText ); > > Those should be really easy to implement too and that will keep the size of the library way down. :) that could be nice, but what if a user doesn't want those methods, i wonder if it would make sense to have a security.core or something,

>>> >>> Advanced users looking for another kind of algorithm/implementation or >>> whatever would still be able to make use of the plain and straight >>> crypto library. >> >> +1 and we should provide examples at least in the docs >>> >>> - What is the best way to package this library? Bower? >> >> If we're going to create some sort of wrapper object then it would just be part of AeroGear.js and by doing that would be packaged and available via Bower. >>> >>> Thoughts? >> >> Great start and great thoughts! >>> >>> -- >>> abstractj >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev