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

[canton]

Hi, bitcoinpaperwallet.com author here.

Over on GitHub, artiomchi and I have been working on adding BIP38 support. As some of you know, I've been extremely cautious/slow/dragging my heels with BIP38 implementation since it's relatively new and not especially well supported by wallet software and services.

During testing, we uncovered an issue with Safari version 6.05 in which BIP38 encrypted wallets end up with a different (essentially wrong and invalid) "6P..." private key. The only way to decode one of these wallets is to use Safari 6.05 for decryption as well. If you upgrade your browser after printing a BIP38 wallet using Safari 6.05, you won't be able to decrypt it unless you find some way to downgrade back to 6.05.

This is a problem endemic to most (all?) services implementing BIP38 via Javascript -- bitaddress.org, etc. It doesn't impact https://bitcoinpaperwallet.com because we haven't deployed BIP38 (yet).

As a preliminary step until a fix is in place, I recommend:

1. Do not use Safari version 6 to make any new BIP38 wallets

2. If you already used Safari version 6 to make BIP38 wallets, decrypt those paper wallets right now (using Safari 6, nothing else will work) and keep an unencrypted paper backup somewhere safe. Consider making new BIP38 wallets using Chrome or Firefox, and use them to receive funds from your Safari 6-encrypted wallets. Once you're sure your safari-6 BIP38 encrypted wallets are empty, discard.

Here are the relevant threads if you want to dig into the nitty gritty, or contribute your own tests/validation:

https://github.com/cantonbecker/bitcoinpaperwallet/pull/6
https://github.com/pointbiz/bitaddress.org/issues/56
https://github.com/mannkind/bit2factor.org/issues/2

Huge thanks to /u/artiomchi for his excellent work bringing BIP38 to bitcoinpaperwallet.com and for helping to narrow down this possibly alarming issue.

[rammy2k2]

thanks for heads-up

[casascius]

Aren't there unit tests that would catch this?  Or are they only run when explicitly requested? (imagine unit testing this would be slow, so it's understandable to not be automatic)

[canton]

Aren't there unit tests that would catch this?

Yes. For example, bitaddress.org asynchronous unit tests for BIP38 encryption and decryption (add ?asyncunittests=true to the URL) fail when using safari 6.05. 6.1 may be fine. Not sure about other 6.x versions. Specific failures vary each time you run it because there's an element of chance. (Never a good thing for a two-way math problem, eh?)

I speculate (based on web stats to bitcoin related sites) that safari 6.05 may have been used for as much as 2.5% of BIP38 wallet generation. So while it's not a hugely important browser, it's probably worth (1) finding a work-around for Safari 6.05 on all impacted sites, and (2) planning for some sort of reverse compatibility so that wallets already made using Safari 6.05 can still be recovered two or three years down the road when nobody still has 6.05 installed.

Here's the deepest investigation into this issue as far as i know:

https://github.com/pointbiz/bitaddress.org/issues/56

[pointbiz]

Thanks for doing a PSA.

[hynx]

What's up with people relying so badly on javascript, specially when you are inside a browser, to perform such sensitive tasks ?

[fluffypony]

What's up with people relying so badly on javascript, specially when you are inside a browser, to perform such sensitive tasks ?

Because it's completely client-side, so nothing touches their server. You can also save the HTML file to disk and use it on an air-gapped machine (ala WarpWallet). That can't be done on a server-side app. Also, JavaScript in an HTML page is a LOT simpler to do than writing a cross-platform app from scratch to do the same thing.

[hynx]

What's up with people relying so badly on javascript, specially when you are inside a browser, to perform such sensitive tasks ?

Because it's completely client-side, so nothing touches their server. You can also save the HTML file to disk and use it on an air-gapped machine (ala WarpWallet). That can't be done on a server-side app. Also, JavaScript in an HTML page is a LOT simpler to do than writing a cross-platform app from scratch to do the same thing.

I see you misinterpreted what I meant. I never meant to say that someone else should run this in behalf of someone else (i.e., I'm not implying in any way that this should be ran in a server someone else owns). I also know what Javascript is...

You never use the standard Javascript, with its basic core, alone in any of these tasks. So you rely in the author including a lot of other libraries into his code, creating a huge mess of a Javascript code. Last time I looked through this specific code, it was a huge repetitive mess. The browser is an environment subpar for dealing with cryptography, since it tries to create a "secure" environment for you by restricting a lot of what you can do. On the other hand, there are perfectly fine programming languages that are cross-platform and can do most of what this requires, and then you can clearly include separated extra-libraries to do whatever else is left that is not included in the language. Yes, it is a bit harder to execute that since you won't be in your typical browser, but you get the benefit of having the entire environment unrestricted for the code -- which should be your primary goal when dealing with such sensitive security tasks.

[casascius]

This may seem like a belated idea, but it occurred to me that a mini unit test that used much less expensive scrypt parameters but ran always would still catch a big swath of potential errors at a fraction of the resource cost.  This is because a bug that breaks scrypt should presumably and in all likelihood break it completely.

[canton]

This may seem like a belated idea, but it occurred to me that a mini unit test that used much less expensive scrypt parameters but ran always would still catch a big swath of potential errors at a fraction of the resource cost.  This is because a bug that breaks scrypt should presumably and in all likelihood break it completely.

Seems like a good idea to me!

BTW we found a work-around at https://bitcoinpaperwallet.com -- seems to reliably encrypt/decrypt now on Safari 6.05.

Bit2factor.org implemented a work around as well. I'm not sure what's up at bitaddress.org and other sites. I think they may still be generating bad BIP38 on Safari 6.05. I still find this fairly alarming since that means that paper wallets are still being generated that will produce heart-attacks when the owner tries to decrypt them down the road using a different browser.

[joeventyra]

Hi, bitcoinpaperwallet.com author here.

Over on GitHub, artiomchi and I have been working on adding BIP38 support. As some of you know, I've been extremely cautious/slow/dragging my heels with BIP38 implementation since it's relatively new and not especially well supported by wallet software and services.

During testing, we uncovered an issue with Safari version 6.05 in which BIP38 encrypted wallets end up with a different (essentially wrong and invalid) "6P..." private key. The only way to decode one of these wallets is to use Safari 6.05 for decryption as well. If you upgrade your browser after printing a BIP38 wallet using Safari 6.05, you won't be able to decrypt it unless you find some way to downgrade back to 6.05.

This is a problem endemic to most (all?) services implementing BIP38 via Javascript -- bitaddress.org, etc. It doesn't impact https://bitcoinpaperwallet.com because we haven't deployed BIP38 (yet).

As a preliminary step until a fix is in place, I recommend:

1. Do not use Safari version 6 to make any new BIP38 wallets

2. If you already used Safari version 6 to make BIP38 wallets, decrypt those paper wallets right now (using Safari 6, nothing else will work) and keep an unencrypted paper backup somewhere safe. Consider making new BIP38 wallets using Chrome or Firefox, and use them to receive funds from your Safari 6-encrypted wallets. Once you're sure your safari-6 BIP38 encrypted wallets are empty, discard.

Here are the relevant threads if you want to dig into the nitty gritty, or contribute your own tests/validation:

https://github.com/cantonbecker/bitcoinpaperwallet/pull/6
https://github.com/pointbiz/bitaddress.org/issues/56
https://github.com/mannkind/bit2factor.org/issues/2

Huge thanks to /u/artiomchi for his excellent work bringing BIP38 to bitcoinpaperwallet.com and for helping to narrow down this possibly alarming issue.

thanks for the guideline. i almost got pissed off. decrypting the wallet did not work with anything else but now it worked when i tried with Safari 6.

[casascius]

One of my Macs has Safari 6.0.5.  I wonder what's the best way to preserve the browser in case it's useful for someone's future recovery.  Maybe I .dmg the harddrive.  Also would need to save affected versions of the scripts.  (Note, a quick test on bitaddress.org produces valid BIP38 that I was able to decrypt on a different computer using Chrome)

(also maybe 6.0.5 != 6.05?)

[canton]

a quick test on bitaddress.org produces valid BIP38 that I was able to decrypt on a different computer using Chrome) (also maybe 6.0.5 != 6.05?)

The Safari javascript bug is worse (less predictable) than that. It's not a consistent encrypt/decrypt failure. It's around 50%, and only on the *first* pass. The deal with the JIT compiler bug had something to do with initialization, where the first effort has a 50/50 chance of making a bungled key, and subsequent efforts are okay. Crazy-making.

[casascius]

a quick test on bitaddress.org produces valid BIP38 that I was able to decrypt on a different computer using Chrome) (also maybe 6.0.5 != 6.05?)

The Safari javascript bug is worse (less predictable) than that. It's not a consistent encrypt/decrypt failure. It's around 50%, and only on the *first* pass. The deal with the JIT compiler bug had something to do with initialization, where the first effort has a 50/50 chance of making a bungled key, and subsequent efforts are okay. Crazy-making.

I wonder if it's possible to know what the incorrect behavior is in order to deliberately reproduce it with code in a properly functioning environment, and perhaps to archive a reference version of such a tool that can recover bungled keys.

[Remember remember the 5th of November]

Perhaps websites like these should include a short self-test during running to check if it produces valid results?