...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.
Some features of bitcore will be too large to be included in the browser bundle
by default. Since BIP39 pretty much requires the giant list of words to be
used, I am excluding it by default. The ability to exclude some features by
default will become useful with some particularly large features to come,
particularly BIP70.
Ryan X. Charles
Manuel Araoz
Matias Alejo Garcia
Petros Angelatos
Devrandom
Gabe
yangit