[aerogear-dev] JavaScript Crypto

[Sebastien Blanc]

On Tue, Sep 24, 2013 at 2:05 PM, Kris Borchers <kris at redhat.com> wrote:

>
> 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.
>

:) Ok , that was also pretty obvious for me  but maybe not for the whole
community

> >
> > 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.
>
Yes that makes sense.


> >
> > 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
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130924/a837cfde/attachment-0001.html