[aerogear-dev] JavaScript Crypto
Kris Borchers
kris at redhat.com
Tue Sep 24 08:05:54 EDT 2013
On Sep 23, 2013, at 2:38 PM, Sébastien Blanc <scm.blanc at gmail.com> wrote:
> Do we also plan to use this encrypt/decrypt module when storing data using our datastore facilities ?
I thought that was kind of obvious that this would be an option.
>
> 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 …
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.
>
> Envoyé de mon iPhone
>
> Le Sep 23, 2013 à 21:31, Bruno Oliveira <bruno at abstractj.org> a écrit :
>
>> Hi gentlemen, I tried to put our ideas together into a gist
>> https://gist.github.com/abstractj/f1229ae075f8e6688c75. Feel free to
>> fork and change, here comes the content:
>>
>>
>> # AeroGear JS Crypto
>>
>> # Goals
>>
>> - Behind the scenes our developers will make use of sjcl
>> (http://crypto.stanford.edu/sjcl/) with wrappers to the basic
>> functionalities like: encrypt, decrypt, password salting and key pair
>> generation.
>>
>> - Advanced developers will be allowed to make use of the pure sjcl
>> implementation.
>>
>> - The pattern of AeroGear.js without the use of new keyword must be
>> followed. Ex:
>> https://github.com/aerogear/aerogear-js/blob/master/src/pipeline/aerogear.pipeline.js#L67
>>
>> - More user friendly interface could be provided like:
>>
>> AeroGear.encrypt("blah");
>> AeroGear.decrypt( cipherText );
>>
>> - Built as a separated module
>>
>> # API initial definition/decision (draft)
>>
>> ## Encryption
>>
>> - Key generation process for encryption "automatically" or explicity?
>>
>> - Automagically
>> AeroGear.encrypt("blah"); //key is generated behind the scenes
>> AeroGear.privateKey; // could provide the generated key
>>
>> - Explicit (+1 from my side)
>> var myKey = AeroGear.generateKey;
>> AeroGear.encrypt(mykey, "blah");
>>
>> ## Decryption
>>
>> - Option 1
>> AeroGear.privateKey = myKey
>> AeroGear.decrypt(nonsenseciphertext);
>> - Option 2
>> AeroGear.decrypt(mykey, nonsenseciphertext);
>>
>> ## Open questions
>>
>> - Do we need a separate repository?
>> - Would the keys be automatically generated by default during the
>> encryption process?
>> - What would be the best way to provide the keys for encryption?
>> - Will the AG JS crypto library be tied to AeroGear JS? For example:
>> Users just looking for crypto, could make use of our work?
>>
>>> Kris Borchers <mailto:kris at redhat.com>
>>> September 23, 2013 3:07 PM
>>> 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
>>> Lucas Holmquist <mailto:lholmqui at redhat.com>
>>> September 23, 2013 3:04 PM
>>> 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,
>>>
>>>>>> 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
>>> Kris Borchers <mailto:kris at redhat.com>
>>> September 23, 2013 3:01 PM
>>> 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. :)
>>>>> 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
>>> Kris Borchers <mailto:kris at redhat.com>
>>> September 23, 2013 2:40 PM
>>> 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.
>>>> 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
>>> Bruno Oliveira <mailto:bruno at abstractj.org>
>>> September 20, 2013 12:05 PM
>>> 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.
>>>
>>> - 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. 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);
>>>
>>> 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.
>>>
>>> - What is the best way to package this library? Bower?
>>>
>>> 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
More information about the aerogear-dev
mailing list