Re: [aerogear-dev] JavaScript Crypto

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... - 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@redhat.com> > September 23, 2013 3:07 PM > On Sep 23, 2013, at 1:04 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > >> On Sep 23, 2013, at 2:01 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >>> On Sep 23, 2013, at 12:40 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> >>>> On Sep 20, 2013, at 10:05 AM, Bruno Oliveira <bruno(a)abstractj.org&gt; 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 > Lucas Holmquist <mailto:lholmqui@redhat.com> > September 23, 2013 3:04 PM > On Sep 23, 2013, at 2:01 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> On Sep 23, 2013, at 12:40 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >>> On Sep 20, 2013, at 10:05 AM, Bruno Oliveira <bruno(a)abstractj.org&gt; 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(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 > Kris Borchers <mailto:kris@redhat.com> > September 23, 2013 3:01 PM > On Sep 23, 2013, at 12:40 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> On Sep 20, 2013, at 10:05 AM, Bruno Oliveira <bruno(a)abstractj.org&gt; 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(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 > Kris Borchers <mailto:kris@redhat.com> > September 23, 2013 2:40 PM > On Sep 20, 2013, at 10:05 AM, Bruno Oliveira <bruno(a)abstractj.org&gt; 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(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 > Bruno Oliveira <mailto:bruno@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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev