...i.e., bignums, numbers, and strings. Also, ensure that if you try to
multiply a buffer, it should be exactly 32 bytes. Eventually this "multiply"
function will be replaced with a more conventional "mul" function, but not yet.
...by using sjcl.mode.cbc.encrypt/decrypt rather than sjcl.encrypt/decrypt. The
difference is that the sjcl.encrypt/decrypt functions are really convenience
methods designed to encrypt and decrypt strings, but don't play nice with
binary data, as revealed in the tests in this commit and the previous commit.
Basically, if you use them to encrypt and decrypt binary data as a string, it
will return the wrong result or an error.
The solution is to use the block cipher directly, in this case sjcl.mode.cbc.
This also has the advantage of fewer format conversions - no converting to
base64 and JSON strings. This makes things faster. Also, it is actually correct
unlike the previous method.
In the browser, sometimes the config for bignum wasn't being set up if (somehow
... still not sure how this is possible) you use bitcore without using
require('bitcore'). This would by pass the code that set the config for bignum.
Solution is to put the config for bignum in bignum itself (in the browser).
This fixes, in particular, an issue with base58 where it was depending on
bignum having the proper config.
Also I add the base58 tests to run in the browser which they weren't
previously.
And finally I add a small test for Bignum in the browser that makes sure the
config is set properly.
...no longer relies on Manuel's repo hostig a version of "bignum" that actually
contained bignumber.js. This moves bignumber.js internally and removes bignum
from the browser build process. Also adds a bitcore.Bignum that links to the
right thing. In node, browser.Bignum is require('bignum'). And in the browser,
bitcore.Bignum is is now Bignumber.js (same as before ... except bignumber.js
is now inside bitcore).
Generating random numbers properly depends on the platform. The new
getRandomBuffer method does the right thing on the right platform. It will
sometimes fail due to insufficient entropy. The getPseudoRandomBuffer class is
also provided that will never fail, but it is not cryptographically secure and
should not be used for keys.
