[WIP] Add jp tests

[dabura667]

hmmm... this is not good.

It looks like the tests are not checking right... I checked Copay's BIP44 addresses and they matched up with the addresses generated by the test vectors I made, but for some reason it's not working here...

Perhaps there is an error in my code.

[dabura667]

OK.

I found where the problem lies, but I can't fix it:

the problem lies in pbkdf2.js

The algorithm deviates from other pbkdf2 libraries when the string value of salt contains non-ASCII characters.

It creates a Buffer with UTF-8 bytes (all Japanese are 3-byte UTF-8) with 3 bytes per character... and it looks like a LOT of things in pbkdf2.js are relying on salt.length (after becoming Buffer)

So I think maybe one of the steps in the pbkdf2 algorithm is based on the assumption that 1 letter = 1 byte and that salt.length will be the same before and after converting to Buffer.

This should be reported upstream as well.

[dabura667]

I have been comparing /stayradiated/pbkdf2-sha512 with https://www.ietf.org/rfc/rfc2898.txt and other implementations like https://code.google.com/p/crypto-js/#PBKDF2 (which is used in another JS BIP39 implementation, like Hive-JS and my own https://bip32jp.github.io/english/ ) and https://pypi.python.org/pypi/pbkdf2 (used in Electrum)

I can't seem to find any problems... but all I can say is that the two implementations are the same, and only /stayradiated/pbkdf2-sha512 has differing results.

My theories so far:

1. Multi-bit UTF-8 strings causing problems?
2. Long salts causing problems? (because each character of Japanese is 3 bytes) (maybe testing it with an ASCII passphrase that is very very long might cause divergence as well?)

I think the problem might even be in the underlying crypto library (node js standard)...

I will try some of these phrases on Copay and see if they diverge from my site.

[dabura667]

ok........ Copay is generating the proper addresses... even with the UTF-8 passphrase

I have no clue anymore... sigh

[dabura667]

Closed in favor of #38