[aerogear-dev] Fwd: JavaScript Crypto

[Lucas Holmquist]

Begin forwarded message:

> From: Kris Borchers <kris at redhat.com>
> Subject: Re: [aerogear-dev] JavaScript Crypto
> Date: September 23, 2013 2:07:42 PM EDT
> To: AeroGear Developer Mailing List <aerogear-dev at lists.jboss.org>
> Reply-To: AeroGear Developer Mailing List <aerogear-dev at lists.jboss.org>
> 
> 
> On Sep 23, 2013, at 1:04 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:
> 
>> 
>> On Sep 23, 2013, at 2:01 PM, Kris Borchers <kris at redhat.com> wrote:
>> 
>>> 
>>> On Sep 23, 2013, at 12:40 PM, Kris Borchers <kris at redhat.com> wrote:
>>> 
>>>> 
>>>> On Sep 20, 2013, at 10:05 AM, Bruno Oliveira <bruno at abstractj.org> 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,  
> 
> 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.
>> 
>>>>> 
>>>>> 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 at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> 
>>> 
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130923/544781bd/attachment.html