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