...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.
There is some kind of problem either in bitcore or sjcl involving the
decodeURIComponent function. I discovered this issue while working on the
network protocol for Copay. Decrypting binary data in sjcl produces problems
due to the way sjcl is interpreting data as strings. I will have to investigate
further tomorrow. For now I am producing this test vector to demonstrate the
issue.
In this commit I have added the 'official' versions 0.1.24 and 0.1.25 to the
repo, and also created a new bitcore-dev.js that is not included in the repo.
bitcoin-dev.js is what we will use for development. When we define a new
version, we create a new bitcore-x.x.x.js file, and point bitcore-latest.js to
that. Note that the bitcore-x.x.x.js files should always be the "main" bundle,
which does not include BIP39 or BIP70, or other large packages.
I have often made the error of using a public key rather than the hash of the
public key when creating an address, leading to invalid addresses. I'm sure I'm
not the only one. This commit follows the principle of "fail early, fail often"
and simply throws an error if you try to insert something other than 20 bytes
long when creating an address, which would be the case when using a public key.
This way that common mistake should be reduced.
