<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 23, 2013, at 1:40 PM, Kris Borchers <<a href="mailto:kris@redhat.com">kris@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br>On Sep 20, 2013, at 10:05 AM, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> wrote:<br><br><blockquote type="cite">Good morning slackland, following with the plan I started a simple draft<br>for JavaScript (<a href="https://github.com/abstractj/cryptoparty-js">https://github.com/abstractj/cryptoparty-js</a>) we have<br>several alternatives outside there the most popular are Crypto-js<br>(<a href="https://code.google.com/p/crypto-js/">https://code.google.com/p/crypto-js/</a>) and the Stanford crypto library<br>(<a href="http://crypto.stanford.edu/sjcl/">http://crypto.stanford.edu/sjcl/</a>).<br><br>Before I finish the whole implementation I have some questions:<br><br>- Currently crypto-js doesn't have support for GCM or ECC, but sjcl has.<br>That's the reason why my choice was sjcl instead of crypto-js, but if<br>you have another good alternative, let me know.<br></blockquote><br>+1 for sjcl if you think it offers everything we need<br><blockquote type="cite"><br>- Create wrappers or not? If you read the unit tests at first glance (at<br>least for me) looks like is too much. Most part of developers are<br>looking for security by default.<br></blockquote><br>+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.<br><blockquote type="cite">My idea is not to hide the library, but<br>provide a simple interface like:<br><br>Crypto crypto = new Crypto;<br>ciphertext = crypto. encrypt("blah");<br>crypto.decrypt(ciphertext);<br></blockquote><br>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.<br></blockquote><div><br></div><div>for example:</div><div><a href="https://github.com/aerogear/aerogear-js/blob/master/src/pipeline/aerogear.pipeline.js#L67">https://github.com/aerogear/aerogear-js/blob/master/src/pipeline/aerogear.pipeline.js#L67</a></div><br><blockquote type="cite"><blockquote type="cite"><br>Advanced users looking for another kind of algorithm/implementation or<br>whatever would still be able to make use of the plain and straight<br>crypto library.<br></blockquote><br>+1 and we should provide examples at least in the docs<br><blockquote type="cite"><br>- What is the best way to package this library? Bower?<br></blockquote><br>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.<br></blockquote><div><br></div><div>i this is the case, then do we need that separate repo?</div><br><blockquote type="cite"><blockquote type="cite"><br>Thoughts?<br></blockquote><br>Great start and great thoughts!<br><blockquote type="cite"><br>-- <br>abstractj<br><br><br>_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/aerogear-dev<br></blockquote><br><br>_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/aerogear-dev<br></blockquote></div><br></body></html>