...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.
eval is unsafe, and the way it was being used in Script and Script interpreter
was not a good enough reason. This commit removes both uses of eval, then
replaces all uses of OP_XXX with Opcode.map.OP_XXX since there's no reason for
those constants to be global.
Signing a message with ECDSA involves using a random number, and this means
that two signatures should never be the same. This commit adds some basic tests
to Key.signSync and Message.sign to make sure this is the case. Also, a new
bitcore.Key should never have the same private key twice. This commit also adds
a basic test to make sure that is the case.
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.
This adds a new Message class with static methods for signing and verifying a
message the same way as bitcoind. (In a nutshell, messages a prepended with
"Bitcoin Signed Message:" before being hashed and signed).
There is one important piece missing ... verifying a signature with an address,
and not a public key. I have not yet implemented this because the cryptography
interface of bitcore does not allow me to derive the public key from a
signature. This will need to be added before verifying from an address is
possible.
Manuel Araoz
Ryan X. Charles
Devrandom
Manan Patel
Gustavo Cortez
Matias Alejo Garcia
olalonde
Gordon Hall
Ruben de Vries