Separate encryption library

[dreamingofelectricsheep]

Have you thought about separating out the various algorithms into a standalone library/libraries? It would be awesome if each algorithm had its own project and package each exposing a uniform interface thus allowing for selective inclusion. Currently there is a ton of encryption libraries and each one is just a featureless blob of algorithms.

Any project that makes use of encryption just includes a file or two, slowly growing their own internal crypto library. It would be awesome if we could just add a git submodule with AES only for example.

Also, if you're interested in speed, asm.js compiled code is just 2x slower than native.

[dlongley]

Forge was originally meant to be designed so it was fairly easy to include just those parts that you really need. That does mean you have to know the dependencies if you're not using require.js or similar, but you can currently include only parts of Forge if you'd like. For instance, you can just include aes.js and its dependencies to get just AES support. The same goes for any of the message digest hashes, hmac, or pki/rsa. What Forge is really lacking, IMO, is some good documentation about this and its other various features.

As for asm.js, it would be nice to see what changes would be necessary to get the most out of AOT compilation. Certainly parts of Forge could be easily adapted to take advantage of it. We (Digital Bazaar) just don't have any resources to put towards it. Well-written PRs related to the subject would likely be accepted, of course. Some of that work could perhaps be done at the same time as moving Forge over to use typed arrays (where available), etc.

[dreamingofelectricsheep]

Forge was originally meant to be designed so it was fairly easy to include just those parts that you really need.

Yeah, well, so were all the other encryption toolkits. The issue I have with this approach is one about the philosophy of developement - there is a ton of duplication everywhere. And there will be more as long as it is easier to include a single js file or two and be done with it.

I was planning on separating out the encryption from openpgpjs into its own library in this style:

--- AES (github project)
package.json
aes.js
other-dependencies/

--- openpgpjs (github project)
aes/   // git submodule
encryption.js

--- encryption.js
var aes = require('./aes');

var allEncryptionModules = { aes: aes }

allEncryptionModules.aes.someStandardInterface(block);

And this is the way forward in my opinion. In this scenario: a) Anyone can add issues and contribute directly to the aes library without bothering to go through openpgpjs. b) No one fears that openpgpjs get stale and unsupported one day - all they care about is the aes lib which they can maintain themselves c) It's easy to add to a project and update via

git submodule add git:git-url-here ./aes
cd aes
git pull

[dlongley]

Using git submodule for this sounds like a good idea. That way, if the individual libraries are split up into their own projects, they aren't just scattered out there in the git universe. This was one of my worries with your suggestion to use multiple projects.

I'm not convinced that the cause of duplication in the JS crypto world is that no project (that we know of) has taken this approach. It may be that the relative obscurity of each of these projects is the underlying cause, not that their obscurity is a result of not taking the approach you suggest. That being said, I do find merit in your suggestion, particularly in the idea that it would be nice for people to contribute directly to more specific crypto projects without having to go through an umbrella project. Using git submodule rather than just a wholesale copy and paste of an external dependency would also allow for optimizations to be contributed back to the original project with much greater ease. That's the strongest selling point, IMO.

When I get more time I may explore this approach further as a redesign for Forge's layout. Intuitively, it doesn't seem like much would have to change at all -- as Forge is already set up to work this way, only minus the separation into individual submodules at the git level.

[dreamingofelectricsheep]

Awesome to hear that. I'll be keeping eye on forge then. Hopefully, we'll end up integrating it into openpgpjs in the future.