<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 24, 2013 at 2:05 PM, Kris Borchers <span dir="ltr"><<a href="mailto:kris@redhat.com" target="_blank">kris@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Sep 23, 2013, at 2:38 PM, Sébastien Blanc <<a href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a>> wrote:<br>
<br>
> Do we also plan to use this encrypt/decrypt module when storing data using our datastore facilities ?<br>
<br>
</div>I thought that was kind of obvious that this would be an option.<br></blockquote><div><br></div><div style>:) Ok , that was also pretty obvious for me but maybe not for the whole community </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> If yes, it could be nice to be able to do as with the pipes and the authenticator : passing a "Encryptor" instance to a Store …<br>
<br>
I would rather just do something like pass in an encryptionKey or something like that which would tell the store to do encryption/decryption and not have to instantiate a crypto object.<br></blockquote><div style>Yes that makes sense.</div>
<div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">><br>
> Envoyé de mon iPhone<br>
><br>
> Le Sep 23, 2013 à 21:31, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> a écrit :<br>
><br>
>> Hi gentlemen, I tried to put our ideas together into a gist<br>
>> <a href="https://gist.github.com/abstractj/f1229ae075f8e6688c75" target="_blank">https://gist.github.com/abstractj/f1229ae075f8e6688c75</a>. Feel free to<br>
>> fork and change, here comes the content:<br>
>><br>
>><br>
>> # AeroGear JS Crypto<br>
>><br>
>> # Goals<br>
>><br>
>> - Behind the scenes our developers will make use of sjcl<br>
>> (<a href="http://crypto.stanford.edu/sjcl/" target="_blank">http://crypto.stanford.edu/sjcl/</a>) with wrappers to the basic<br>
>> functionalities like: encrypt, decrypt, password salting and key pair<br>
>> generation.<br>
>><br>
>> - Advanced developers will be allowed to make use of the pure sjcl<br>
>> implementation.<br>
>><br>
>> - The pattern of AeroGear.js without the use of new keyword must be<br>
>> followed. Ex:<br>
>> <a href="https://github.com/aerogear/aerogear-js/blob/master/src/pipeline/aerogear.pipeline.js#L67" target="_blank">https://github.com/aerogear/aerogear-js/blob/master/src/pipeline/aerogear.pipeline.js#L67</a><br>
>><br>
>> - More user friendly interface could be provided like:<br>
>><br>
>> AeroGear.encrypt("blah");<br>
>> AeroGear.decrypt( cipherText );<br>
>><br>
>> - Built as a separated module<br>
>><br>
>> # API initial definition/decision (draft)<br>
>><br>
>> ## Encryption<br>
>><br>
>> - Key generation process for encryption "automatically" or explicity?<br>
>><br>
>> - Automagically<br>
>> AeroGear.encrypt("blah"); //key is generated behind the scenes<br>
>> AeroGear.privateKey; // could provide the generated key<br>
>><br>
>> - Explicit (+1 from my side)<br>
>> var myKey = AeroGear.generateKey;<br>
>> AeroGear.encrypt(mykey, "blah");<br>
>><br>
>> ## Decryption<br>
>><br>
>> - Option 1<br>
>> AeroGear.privateKey = myKey<br>
>> AeroGear.decrypt(nonsenseciphertext);<br>
>> - Option 2<br>
>> AeroGear.decrypt(mykey, nonsenseciphertext);<br>
>><br>
>> ## Open questions<br>
>><br>
>> - Do we need a separate repository?<br>
>> - Would the keys be automatically generated by default during the<br>
>> encryption process?<br>
>> - What would be the best way to provide the keys for encryption?<br>
>> - Will the AG JS crypto library be tied to AeroGear JS? For example:<br>
>> Users just looking for crypto, could make use of our work?<br>
>><br>
>>> Kris Borchers <mailto:<a href="mailto:kris@redhat.com">kris@redhat.com</a>><br>
>>> September 23, 2013 3:07 PM<br>
>>> On Sep 23, 2013, at 1:04 PM, Lucas Holmquist <<a href="mailto:lholmqui@redhat.com">lholmqui@redhat.com</a>> wrote:<br>
>>><br>
>>>> On Sep 23, 2013, at 2:01 PM, Kris Borchers <<a href="mailto:kris@redhat.com">kris@redhat.com</a>> wrote:<br>
>>>><br>
>>>>> On Sep 23, 2013, at 12:40 PM, Kris Borchers <<a href="mailto:kris@redhat.com">kris@redhat.com</a>> wrote:<br>
>>>>><br>
>>>>>> On Sep 20, 2013, at 10:05 AM, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> wrote:<br>
>>>>>><br>
>>>>>>> Good morning slackland, following with the plan I started a simple draft<br>
>>>>>>> for JavaScript (<a href="https://github.com/abstractj/cryptoparty-js" target="_blank">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/" target="_blank">https://code.google.com/p/crypto-js/</a>) and the Stanford crypto library<br>
>>>>>>> (<a href="http://crypto.stanford.edu/sjcl/" target="_blank">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>
>>>>>> +1 for sjcl if you think it offers everything we need<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>
>>>>>> +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>
>>>>>>> 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>
>>>>>> 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>
>>>>> 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:<br>
>>>>><br>
>>>>> AeroGear.encrypt("blah");<br>
>>>>> AeroGear.decrypt( cipherText );<br>
>>>>><br>
>>>>> Those should be really easy to implement too and that will keep the size of the library way down. :)<br>
>>>> 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,<br>
>>><br>
>>> That would be fine. We could build it as a separate module that just gets tacked onto Core if they want it that way they can leave it and sjcl out if they don't want it.<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>
>>>>>> +1 and we should provide examples at least in the docs<br>
>>>>>>> - What is the best way to package this library? Bower?<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>
>>>>>>> Thoughts?<br>
>>>>>> Great start and great thoughts!<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>
>>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>>> _______________________________________________<br>
>>>>>> aerogear-dev mailing list<br>
>>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>> _______________________________________________<br>
>>>>> aerogear-dev mailing list<br>
>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>> _______________________________________________<br>
>>>> aerogear-dev mailing list<br>
>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> aerogear-dev mailing list<br>
>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>> Lucas Holmquist <mailto:<a href="mailto:lholmqui@redhat.com">lholmqui@redhat.com</a>><br>
>>> September 23, 2013 3:04 PM<br>
>>> On Sep 23, 2013, at 2:01 PM, Kris Borchers <<a href="mailto:kris@redhat.com">kris@redhat.com</a>> wrote:<br>
>>><br>
>>>> On Sep 23, 2013, at 12:40 PM, Kris Borchers <<a href="mailto:kris@redhat.com">kris@redhat.com</a>> wrote:<br>
>>>><br>
>>>>> On Sep 20, 2013, at 10:05 AM, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> wrote:<br>
>>>>><br>
>>>>>> Good morning slackland, following with the plan I started a simple draft<br>
>>>>>> for JavaScript (<a href="https://github.com/abstractj/cryptoparty-js" target="_blank">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/" target="_blank">https://code.google.com/p/crypto-js/</a>) and the Stanford crypto library<br>
>>>>>> (<a href="http://crypto.stanford.edu/sjcl/" target="_blank">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>
>>>>> +1 for sjcl if you think it offers everything we need<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>
>>>>> +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>
>>>>>> 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>
>>>>> 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>
>>>> 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:<br>
>>>><br>
>>>> AeroGear.encrypt("blah");<br>
>>>> AeroGear.decrypt( cipherText );<br>
>>>><br>
>>>> Those should be really easy to implement too and that will keep the size of the library way down. :)<br>
>>><br>
>>> 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,<br>
>>><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>
>>>>> +1 and we should provide examples at least in the docs<br>
>>>>>> - What is the best way to package this library? Bower?<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>
>>>>>> Thoughts?<br>
>>>>> Great start and great thoughts!<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>
>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>> _______________________________________________<br>
>>>>> aerogear-dev mailing list<br>
>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>> _______________________________________________<br>
>>>> aerogear-dev mailing list<br>
>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> aerogear-dev mailing list<br>
>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>> Kris Borchers <mailto:<a href="mailto:kris@redhat.com">kris@redhat.com</a>><br>
>>> September 23, 2013 3:01 PM<br>
>>> On Sep 23, 2013, at 12:40 PM, Kris Borchers <<a href="mailto:kris@redhat.com">kris@redhat.com</a>> wrote:<br>
>>><br>
>>>> On Sep 20, 2013, at 10:05 AM, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> wrote:<br>
>>>><br>
>>>>> Good morning slackland, following with the plan I started a simple draft<br>
>>>>> for JavaScript (<a href="https://github.com/abstractj/cryptoparty-js" target="_blank">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/" target="_blank">https://code.google.com/p/crypto-js/</a>) and the Stanford crypto library<br>
>>>>> (<a href="http://crypto.stanford.edu/sjcl/" target="_blank">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>
>>>> +1 for sjcl if you think it offers everything we need<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>
>>>> +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>
>>>>> 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>
>>>> 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>
>>><br>
>>> 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:<br>
>>><br>
>>> AeroGear.encrypt("blah");<br>
>>> AeroGear.decrypt( cipherText );<br>
>>><br>
>>> Those should be really easy to implement too and that will keep the size of the library way down. :)<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>
>>>> +1 and we should provide examples at least in the docs<br>
>>>>> - What is the best way to package this library? Bower?<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>
>>>>> Thoughts?<br>
>>>> Great start and great thoughts!<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>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>> _______________________________________________<br>
>>>> aerogear-dev mailing list<br>
>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> aerogear-dev mailing list<br>
>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>> Kris Borchers <mailto:<a href="mailto:kris@redhat.com">kris@redhat.com</a>><br>
>>> September 23, 2013 2:40 PM<br>
>>> On Sep 20, 2013, at 10:05 AM, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> wrote:<br>
>>><br>
>>>> Good morning slackland, following with the plan I started a simple draft<br>
>>>> for JavaScript (<a href="https://github.com/abstractj/cryptoparty-js" target="_blank">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/" target="_blank">https://code.google.com/p/crypto-js/</a>) and the Stanford crypto library<br>
>>>> (<a href="http://crypto.stanford.edu/sjcl/" target="_blank">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>
>>><br>
>>> +1 for sjcl if you think it offers everything we need<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>
>>><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>
>>>> 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>
>>><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>
>>>> 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>
>>><br>
>>> +1 and we should provide examples at least in the docs<br>
>>>> - What is the best way to package this library? Bower?<br>
>>><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>
>>>> Thoughts?<br>
>>><br>
>>> Great start and great thoughts!<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>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> aerogear-dev mailing list<br>
>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>> Bruno Oliveira <mailto:<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>><br>
>>> September 20, 2013 12:05 PM<br>
>>> Good morning slackland, following with the plan I started a simple draft<br>
>>> for JavaScript (<a href="https://github.com/abstractj/cryptoparty-js" target="_blank">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/" target="_blank">https://code.google.com/p/crypto-js/</a>) and the Stanford crypto library<br>
>>> (<a href="http://crypto.stanford.edu/sjcl/" target="_blank">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>
>>><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. 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>
>>><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>
>>><br>
>>> - What is the best way to package this library? Bower?<br>
>>><br>
>>> Thoughts?<br>
>>><br>
>><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>
>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
><br>
> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div></div></blockquote></div><br></div></div>