Bitcoin Forum

I would like to offer a 20 BTC bounty for the following: a Javascript implementation of BIP 38 private key decryption, released with an open source license, so anybody can use it on their own web sites.

BIP 38: https://en.bitcoin.it/wiki/BIP_0038

I have already written functioning reference code in C#, the flow can be taken verbatim, you may freely take or incorporate any part of the code.  This code will run under Windows .NET, as well as under Linux and Mac OS X using Mono.  Although the ability to create intermediate codes and addresses would be nice and won't be much work beyond the decryption part, the bounty can be collected in full with just the ability to decrypt all variants of BIP38-encrypted private key.

That reference code I wrote: https://github.com/casascius/Bitcoin-Address-Utility

The UI can be minimal, just two text boxes, one to take the private key and the other to take the passphrase.  When you click a button, the page should either decrypt the private key into some element on the screen, or report that the encrypted private key is invalid (e.g. fails base58 checksum or formatting rules), or that the passphrase is incorrect (if the key is well-formatted but the decryption with the provided passphrase fails to produce a bitcoin address matching the embedded address checksum)

I actually anticipate that this won't be too difficult, and would do it myself other than I think it'll get done sooner if I post a bounty.

The winning solution needs to properly handle the compressed private key flag, as well as the variants of encryption that include and exclude the elliptic curve multiplication step as well as the flag that turns on the presence of a sequence number.

If I were doing it, I'd probably start with much of the code and/or the same dependencies that are used in bitaddress.org, so the basics of handling bitcoin addresses, private keys, base58, elliptic curve points, etc. are already taken care of.  Add scrypt and AES, and perhaps support for decompressing EC points if that's not already there.

The GOAL is so that others who currently accept unencrypted private keys, can easily switch to accepting encrypted private keys as well, just by dropping in a couple of .js files and letting the client browser do all the decryption.

This might be an issue since there is not an official library for scrypt ported to js...

http://stackoverflow.com/questions/7617169/scrypt-implementation-in-javascript (lol, that question was for a Bitcoin-related project also, Tenebrix (https://bitcointalk.org/index.php?topic=45667.0)...)

here maybe, but it looks like it needs some work: https://github.com/cheongwy/node-scrypt-js

---
Whoever wants to pick this up, can also look at my code here https://github.com/notespace/bip38-cracker/blob/master/main.c even though it is a quite hacked together and ONLY works with the EC-multiplied version of BIP 38, not all of them. It does correctly decode keys though. Not sure it will help that much though for a js port...

The second section seems to imply you meant every instead of any right?

Seems cool! Starting research it now...

That one only works for node and uses a lot of external modules. I'm trying to follow the coding style and let it work in the browser but it doesn't look too hopeful with my coding skills.

Yes, decryption of every mode must be supported.  Clarified OP.

In practice, I don't imagine that being the hardest part, especially if you are following my C# code as a template.

I finally have a scrypt implementation in pure javascript that passes all test vectors at http://www.ietf.org/id/draft-josefsson-scrypt-kdf-01.txt. I won't release it now because I plan to go for the bounty. If I somehow abandon that I will put it up on github.

Test vectors

No compression, no EC multiply
Test 1:
Passphrase: TestingOneTwoThree
Encrypted: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg
Unencrypted (WIF): 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR
Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5


Result by decryptbip38.js:

Encrypted key: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg
Passphrase: TestingOneTwoThree
Private key: cbf4b9f70470856bb4f40f80b87edb90865997ffee6df315ab166d713af433a5


Now for the EC version. Shouldn't be much harder.

Can someone provide the ownersalt used for these test vectors? It appears to be missing or I'm misunderstanding something. I need to test the process until the intermediate code.

EC multiply, no compression
Test 1:
Passphrase: TestingOneTwoThree
Passphrase code: passphrasepxFy57B9v8HtUsszJYKReoNDV6VHjUSGt8EVJmux9n1J3Ltf1gRxyDGXqnf9qm
Encrypted key: 6PfQu77ygVyJLZjfvMLyhLMQbYnu5uguoJJ4kMCLqWwPEdfpwANVS76gTX
Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2
Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2
Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519
Test 2:
Passphrase: Satoshi
Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
Encrypted key: 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd
Bitcoin address: 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V
Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH
Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A

The ownersalt is encoded plaintext in the encrypted key and is handled like an IV. Casascius changed BIP 38 since I last looked at it (boo!) and now it seems to be called ownerentropy (which can be 8 random bytes or derived from a 4-byte random number + lot and sequence #.)

Encrypted Key = base58(0x01 0x43 + flagbyte (1 byte) + addresshash (4 bytes) + ownerentropy (8 bytes) + encryptedpart1[0...7] (8 bytes) + encryptedpart2 (8 bytes)).

Actually looking further into the spec it seems like my BIP 38 cracker is now incompatible with the spec with the addition of prefactor and hashing it with ownersalt to get passfactor. :(

So do you figure those test vectors are invalid now?

The test vectors are still valid.

I did make a recent change but then required both modes to be supported. A bit flag enables that change. It allows someone ordering a batch of paper wallets to ensure his intermediate codes aren't reused by building a batch(lot) and sequence number into the salt. Meanwhile the sha256 step allows the sequence number to be incremented without repeating the scrypt - essential for mobile phone performance generating a batch of codes.

The test vectors don't have that flag but I will add one with the flag when I get a chance.

Curious, have you got even the last case with N=1048576?  Mine is crashing the Chrome tab it lives in, and even nodejs (message about running out of memory).  (With the smaller N-values BIP38 needs it works though.)

Here is a test vector for the version with the lot and sequence number.  The Wiki seems to be down otherwise I'd update it.  The Greek characters should also help test for support of UTF-8, which I intend to specify as the required encoding for non-ASCII characters.

Passphrase: MOΛΩN ΛABE
Intermediate code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK
Encrypted private key: 6PgGWtx25kUg8QWvwuJAgorN6k9FbE25rv5dMRwu5SKMnfpfVe5mar2ngH
Private key hex: CA2759AA4ADB0F96C414F36ABEB8DB59342985BE9FA50FAAC228C8E7D90E3006
Unencrypted private key (WIF): 5KMKKuUmAkiNbA3DazMQiLfDq47qs8MAEThm4yL8R2PhV1ov33D
Bitcoin address: 1Lurmih3KruL4xDB5FmHof38yawNtP9oGf
Confirmation code: cfrm38V8G4qq2ywYEFfWLD5Cc6msj9UwsG2Mj4Z6QdGJAFQpdatZLavkgRd1i4iBMdRngDqDs51

Crashes for me too. I think I could possibly get it to work but I'm not going to bother since the BIP38 stuff works.

How far along are you on the whole thing?

I added two test vectors to the wiki page.

I wouldn't worry so much if N=1048576 fails due to resource constraints, it won't be used.

I think I'm done now.  I implemented the lot/sequence number last night, and just sent Casascius the link to my latest code.  Something I maybe should have mentioned to him, is that the performance in Firefox is pretty bad (3x slower than Chrome.)  I'm not sure if the JS engine is just that much worse, or if I'm doing something dumb that's slowing me down.  So maybe performance could use some work, but all test cases are passing.

It looks like it functions as expected.  Would you mind adding it to github as a pull request and provide a bitcoin address for the bounty?

Congrats, I was nearly done but had some annoying bug left. I'll check performance in firefox and see if my code happens to do better though. (Unlikely though if your scrypt is also based on this one: https://github.com/cheongwy/node-scrypt-js)

I submitted a pull request at https://github.com/pointbiz/bitaddress.org/pull/8 . (Edit: demo page at http://scintill.github.com/bitaddress.org-bip38.html )

I'm open to suggestions on improvements, or requests on other ways to package it up.  The core code is pretty short and simple, but it depends on EC crypto, biginteger, AES, SHA256, scrypt, and Base58 coding, so could need some adjustment if anyone would like to use it outside of the bitaddress.org page.  I may also release my scrypt code separately as it looks like there are no other browser-ready implementations.

Please send the bounty to 1GSo3Z3fgsvUH6yKr6s8kJHMFDWvLEuXjs, and thank you!


Yes, my scrypt is based on that, replacing the node module dependencies with Crypto-JS functions.  I also used Web Workers to do 2 scrypt threads in parallel.

Bounty has been paid!

Cool. How about also adding an option to bitaddress.org's paper wallet to allow generation of the encrypted private key and bitcoin address. I would even go so far as to not show the unencrypted version at all.

Done, just cleaning up the code for the pull request. I'll have it ready in a while. The only problem (other than the speed) is that the BIP38 encrypted keys are longer than the height of the pretty notes and the font is already pretty small. The original image for the note needs changing to accommodate. Also needs to change 'Private key' to 'Private key (BIP38 encrypted)' or something. My graphics/css manipulation skills are awful, so I can't really help.
http://img20.imageshack.us/img20/9120/screenshotavw.png

My version splits the key into two lines and says "Password Required".

Ideal to keep them consistent.

I had changed the font size slightly and got it to fit while still readable, most will use the QR code rather than trying to punch in 60 random characters anyway.
Anyway, yea I can split it to 2 lines, you want both encrypted and plain-text keys split on 2 lines?

I'm generating non-compressed keys. I guess I should add an option to choose.

Thanks for the reminder about tests!

In the mean time, you can find the code here to play with :)
https://github.com/Zeilap/bitaddress.org

I would suggest always generating non-compressed keys until community-wide support for importing compressed keys is ubiquitous.  The option to compress the keys takes more "bytes" of the user's brain than it saves bytes on the block chain, and isn't worth the user finding out that he "can't" import his key in the venue of his choice because they don't support compressed keys.

Done. I modified the image to include the word 'Encrypted' below 'Private Key'. Also I changed the colour to blue for encrypted paper wallets to provide distinction between encrypted/unencrypted paper wallets - a version in the original yellow is included in case you really like yellow, just delete 'note_encrypted.png' and rename 'note_yellow.png' in its place.

http://img191.imageshack.us/img191/2761/screenshotcoh.png

In case you or anyone else doesn't know, to try it you can simply download the code by clicking the 'Zip' button github, then unzip anywhere you like and double-click 'bitcoinaddress.org.html'.

here's my address for the bounty :)
1X3XKkw7tnYSQknKPLqLrJkdMzyHoZ7Jf

Unit tests are problematic, I'll explain:
The encryption/decryption is implemented asynchronously, so when the unit tests run, the browser will be trying to perform 6 decryptions and 4 encryptions from the official test vectors and 2 random encryption-decryption cycles, all at once! Also because they are run asynchronous the encryption/decryption tests are still running well after the alert that says all synchronous tests have completed.

There's a warning in the source of the unit tests to say not to run all the tests at once or your browser will probably crash (certainly did on chrome) or take forever on Firefox.

I'll try to implement something to run the call one after another. In the mean time you can comment out some of the tests so that only a few can run. Also if you open the javascript console (in Firefox 'Web developer' menu, Chrome in 'tools' menu) you can see the messages of individual tests passing (they take a while!) - they only alert when they fail.

Also, thanks for the bounty :)

Here are two things I would strongly push for before considering this worthy for real world use and awarding a bounty:

1. The methodology for creating the keys.  I notice the sample one starts with 6PR.  This indicates the non-EC-multiplication is being used.  This also indicates that the scrypt must be re-run for e-v-e-r-y s-i-n-g-l-e a-d-d-r-e-s-s.  It's going to be really slow to generate a batch.

If you're going to generate a batch of private keys all with the same passphrase, you should use the EC multiplied method, and simply increment the sequence number.  This way you don't have to repeat the scrypt.

2.  The layout of the private key is confusing.  It looks as though there are two fields: "Private key: 6PRblablhablah, Encrypted: blahblahblah".  The average user will think he has two pieces of information, one called "Private key" and one called "Encrypted", this is unduly confusing.  It should be clear to the user that he has a private key that requires a password.  (Encrypted != Requires Password, since password is not the only kind of key usable for encryption)

This is somewhat off-topic, but has anyone considered refactoring the code to have the pieces split into separate files that are built into one big file for release?  I think it is a bit unmanageable with all the scripts, CSS, base64 images in one huge file, with deeply-nested indentation.  I might have done it earlier, but didn't want to waste the time if pointbiz rejected it for whatever reason.


Author of the decryption code for Casascius' bounty here.  I enjoyed having them all run concurrently on my 8-core machine, others may not like it so much. :)  It should be possible to chain the asynchronous tests so they run serially, and they probably should be chained into the standard tests so the alert at the end can mean the async tests passed too.  (There could also be a flag to force scrypt to run synchronously for the tests, but then I would worry about the web-worker asynchronous version not being tested.)

Yea, I've since implemented some asynchronous serialization code for the testing and used your nice busy indicator so that it doesn't appear everything has finished when it has really only just begun.
Had to add a 5 second wait between each BIP test though because the VM is not fast enough at releasing memory from the previous test - repeatedly ate up all 8gig on my machine lol.

scintill, I'm in the process of reviewing the original pull request.

I looked at the Crypto-JS dependencies in your pull request and have decided to upgrade the entire Crypto-JS code used in bitaddress.org to v2.5.4
Each file from Crypto-JS now is in it's own html script tag. To make it easier to upgrade in the future and I commented with the version number and original file name.

I still need to merge the Scrypt code and the unit tests and UI etc. In v2.3 I modified the unit test code and how it outputs. Now it's a text area. I'll try and get the async unit tests incorporated with the textarea.

I haven't put much thought into splitting the file into pieces and having a build process. I've just put up the same file on github that I put on the website. In Visual Studio you can collapse script tag blocks so I have chosen to divide the code into blocks, in most cases, that correspond to the files in the external dependencies. That helps me navigate the various parts of the code and maintain them with upstream dependencies.

I'm not sure yet if I'll release your pull request alone and then Zeilaps or both at the same time.

OK.  Be aware I stripped out some stuff from BlockModes.js that wasn't needed for our purposes, which you may or may not want to do as well.


There's definitely a simplicity and transparency to having a single file as you have.  I see now why you split them into separate blocks, and that's fine.

I am not sure how well the scrypt will or will not run in various browsers, but I would like to throw out the idea of having it so that if you're using a browser that is unlikely to perform the encryption well or is likely to crash, simply disable the encryption option and say "To enable encryption, please use Firefox or Chrome" etc.

This may not be an issue if the scrypt code can be tuned to run well under other browsers.  If Chrome simply performs much faster, it may be worthwhile to point out that they'll be waiting extra long due to their browser choice, and that if they'll be doing a lot of these, to use Chrome instead.

Good idea.  I know IE9 takes two minutes and becomes unresponsive doing a non-EC-multiplied decryption.  It could potentially be more responsive if we chunked up the scrypt loops into separate setTimeout() calls with some delay every now and then, but I'm not sure it's worth the effort.  I haven't tested IE10, but it supports web workers, so I think it will be more responsive and probably faster since it can do 2 threads.

Speaking of crashing the browser, I just tried running my unit tests and Chrome (on Linux) is consistently crashing.  When I changed the BIP38 decryption tests to not run in parallel, it stopped crashing.  It also runs fine doing a manual decryption.  I notice there's been a Chrome update pushed out since I released the pull request, which is the only reason I can think for this change.

I added the intermediate point creation and use it now to generate the batch of keys. It runs much faster than before :P

Relevant and important thread:

PSA: Do not use Safari 6 to make BIP38 encrypted paper wallets.

https://bitcointalk.org/index.php?topic=416324.0