version 2

[dominictarr]

I'm working on v2,

here is the basic idea:

• all parts will come from separate modules (sha.js for hashing, whatever @jducanator or @jdeblese publish!)
• what test frameworks a submodule uses is up to it's maintainer.
• all (non-dev) deps will be fixed to an exact version. maintainers should post an issue when you push a new version, so code can be reviewed.
• to test, you should generate expected results with node (i.e. openssl, a validated crypto implementation), save that as JSON (use base 64) and then require('./data.json') this will make it easy to run exactly the same tests in node and the client. If there is a standard set of vectors, with matching output, you should use those, if not generate some from node.

I minimum set of operations I'd like to support:

• createHash (sha1, sha256, md5) (done)
• createHmac (as above) (done)
• randomBytes (done)
• pseudoRandomBytes
• createDiffieHelman (use @jdeblese or @jdcanator's stuff, when they publish module)
• createCipher (aes) (probably port from forge or crypto-js)
• createDecipher (aes)
• createSign (rsa)
• createVerify (rsa)

this will give a minimal useable subset of the node api, although, the set of algorithms is lessened.

@jducanator @jdeblese @chrisdickinson @brianloveswords @tonistiigi @juliangruber

[dominictarr]

@jduncanator I know what unrolled code looks like, posting that into this issue doesn't help. I have already refactored browserify to be mulitple modules, and if you can just publish his latest work as a module then I'll use that too. I don't really care whether or not it's an org.

@jduncanator the fork you are working from is out of date. just please publish the hashes you've done as their own modules as you go. that is the whole point of modules!

[jduncanator]

I understand. I'm not publishing them until I'm happy with the improvements and until I've finished other modules. These are being used in production so when I push changes to my site, I'll publish a module.

AES is coming too.

EDIT: Looking into AES and other Ciphers. We are going to run into issues very quickly with the lack of a decent random number generator implementation in crypto-browserify. I have my CSPRNG but work won't let me publicly make it available, atleast until we push all our new code to the website. Sorry.

[jprichardson]

I have already refactored browserify to be mulitple modules, and if you can just publish his latest work as a module then I'll use that too. I don't really care whether or not it's an org.

@dominictarr Sorry, I didn't see any deps for crypto-browserify other than sha1.js so I assumed it wasn't refactored into multiple modules. But nice work on the project overall. I was just thinking that an org would give more clarity to users and developers. If you should change your mind and want to do the crypto-browserify org, let me know - naturally, you'd be the owner.

[dominictarr]

there is only sha.js which implements sha1 and sha256. there is still md5 the old way, but of course you should not use md5 (or sha1) in a new system.

I would like to bring in https://github.com/jduncanator/dh-browserify but it needs tests.

aes is the next thing, and then we'll have a shallow coverage of the openssl features (we can do the sort of things openssl can do, although we won't support all the algorithms)

then sign and verify, though I have been working on stuff for curves, since that in better than RSA nowadays.

[jprichardson]

Excellent. I have AES completed: https://github.com/cryptocoinjs/aes with tests included. It's extracted from SJCL. It still needs ebc and cbc bolted on though.

[jduncanator]

@dominictarr & @jprichardson: you are both still missing the point that without secure and reliable random number generation, all symmetric ciphers a basically useless. We need a decent and secure source of IVs and we can't do that with Math.random

[jprichardson]

@jduncanator how do they use a RNG? AES doesn't, at least not that I'm aware of. (Forgive the ignorance on my part). I'm fully aware of the problems of using an insecure RNG btw. Also, what's wrong with window.crypto.getRandomValues() ?

[jduncanator]

When sending AES encrypted messages across the network (anywhere it can be "publicly" seen) the IV needs to be random and unpredictable. In fact, that's basically what the algorithm depends on. When encrypting files, the IV is single use so that's fine, but just like TCP sequence numbers, AES encrypted messages need to have 100% unpredictable IVs to avoid plain text attacks and other side channel attacks. Weak IV = Weak Encryption. Math.random is extremely predictable in the overall scheme of random number generation so we need something A LOT better.

[jprichardson]

@jduncanator Yeah, I'm aware of the weakness in Math.random() for cryptography. What's wrong with using window.crypto.getRandomValues() though?

[jduncanator]

It's not widely supported and we would be throwing away backward compatibility.

[jprichardson]

@jduncanator If there is anything worse than a shoddy RNG, it's making people feel safe with bad crypto. i.e. IMHO, screw the legacy browsers. Crypto is too important to get incorrect. Yeah, there are seeding techniques a la http://bitaddress.org, but they're not very user friendly.

[jduncanator]

Sadly unsupported browsers are more numerous than you think. Sure chrome and Firefox support it (I think) but not even internet explorer 9 has crypto API and that makes up 30% browser share. I'll share my ported Linux CSPRNG as soon as I can under a license work lets me...

[dominictarr]

@jduncanator hmm, wheren't you working on getRandom? what happened to that?

[jduncanator]

@dominictarr Thats what I was talking about above.

[dominictarr]

we can just borrow the RNG from sjcl until we want to rewrite it.

[dcousens]

We are currently at version 3. Perhaps best to close and open a new issue if necessary? Most of the goals were reached, granted however the lack of a substitute RNG still exists.