API

[jason0x43]

This is the base API for crypto, along with the Node-backed implementation.

[kfranqueiro]

My initial thoughts/concerns on this are largely around limits it imposes on extensibility. Because hash and sign have distinct exported functions, it seems like it'd be difficult for people to add additional algorithms or provider features if they wanted without needing to basically eschew the default top-level modules (despite the fact that the underlying provider could potentially accommodate as many algorithms/features as they want).

I'm also at least a little concerned that there's more than a fair share of indirection going on here and I'm not sure it's entirely warranted. Currently main isn't something that's typically expected to be directly used (unless the user wants to override the default provider), but looking at the top-level hash or sign modules leads you through an adventure through create<Whatever>Function, back to main, then to whichever implementation-dependent subfolder applies. It doesn't sound that bad but it was pretty disorienting when first looking at it.

[jason0x43]

There's only one level of indirection src/hash.method -> provider.method(), where provider is either src/node/hash, src/script/hash, or src/webcrypto/hash. Hmmm...that may not be super apparent, though.

Some of the messiness is due to competing ways of dividing this up. On the one hand, there are some distinct sets of functionality: hashes, signing functions, and others (key generators, ciphers, ...). On the other hand, there's the platform-based breakdown: node, browser, and pure JS. The current API uses both divisions, which makes for a lot of unnecessary exports.

[jason0x43]

I'm revising this to be a bit simpler and more easily extensible.

[kfranqueiro]

This should be in a dedicated has module. See dojo-dom/has for an example.

[kfranqueiro]

Some of the comments I've left on the hash side of things are also applicable to sign.

This branch needs to be rebased against master.

Test coverage probably isn't quite where we'd like it to be yet. A few things that aren't covered:

• NodeHasher#abort and NodeHasher#start (both before and after the provider loads)
• getHash and getSign with invalid algorithm strings
• calling sign before the provider has loaded
• calling setProvider
• I'm not sure how we would go about testing the "else if not AMD" branches of getProvider...

[jason0x43]

This has been rebased on master and cleaned up based on Ken's comments. Test coverage is much improved. The only untested code is loader-related; more of that will be exercised when we have additional providers.

[dylans]

Typo

[jdonaghue]

might want to move this to the top of the file since it is first used in the SignFunction interface definition