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

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

From: Kris Borchers <kris(a)redhat.com&gt; 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&gt; Reply-To: AeroGear Developer Mailing List <aerogear-dev(a)lists.jboss.org&gt; 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

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

Do we also plan to use this encrypt/decrypt module when storing data using our datastore facilities ?

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 …

Envoyé de mon iPhone Le Sep 23, 2013 à 21:31, Bruno Oliveira <bruno(a)abstractj.org&gt; 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... > > - 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Sep 23, 2013, at 2:38 PM, Sébastien Blanc <scm.blanc(a)gmail.com&gt; 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(a)abstractj.org&gt; 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... >> >> - 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 > > _______________________________________________ > 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

I think I made it clear at my roadmap http://staging.aerogear.org/docs/planning/roadmaps/AeroGearSecurity/, please see the section 1.3.0. If not, please attach a PR.

Sebastien Blanc wrote: > :) Ok , that was also pretty obvious for me but maybe not for the > whole community -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev