[ANN] bitaddress.org Safe JavaScript Bitcoin address/private key

[osmosis]

What do you think?

Encryption-protected paper wallets, excellent!

+1

I think strongcoin.com and blockchain.info/wallet  are doing something similar. Would be great to see it in bitaddress as well, since its a simple standalone tool.

[1713917670]

1713917670

[1713917670]

1713917670

[1713917670]

1713917670

[dooglus]

I think strongcoin.com and blockchain.info/wallet  are doing something similar. Would be great to see it in bitaddress as well, since its a simple standalone tool.

Yes, but BitAddress has the unique feature of working entirely offline once you've saved a copy of the webpage.  I can copy the saved page using a USB stick to an offline computer and run it there.  Then my private keys are never on a machine connected to the Internet.

[pointbiz]

What do you think?

Encryption-protected paper wallets, excellent!

+1

I did not realize there was interest in this feature. I've shied away from any passphrase protection features because I'm wrestling with the idea if it's better for bitcoins to be stolen then to be lost... there might be a greater chance of people forgetting versus people actually getting robbed. Especially in these early days... that being said I passphrase protect my desktop wallet.

And now for the workaround....

With the current version of BitAddress you can go to the Wallet Details tab and enter a passphrase (instead of a private key) and then you will be prompted to confirm you want to SHA256 hash your passphrase to generate a bitcoin address along with private key details. You can copy/paste the bitcoin address somewhere and then print it, or print the whole page and physically destroy the private key, etc. Then you've accomplished your goal of having a bitcoin address and accessing it's private key through a passphrase. No need to print an encrypted private key that later needs a passphrase anyway to decrypt.

Of course, it's not as elegant as the feature you have described. The current functionality is one passphrase to one bitcoin address versus what you proposed sounds like one passphrase to many bitcoin addresses.

I don't think this would be too hard to implement on the Paper Wallet tab... I'd probably need to include an AES javascript library... I'll think about it.

[casascius]

I don't think this would be too hard to implement on the Paper Wallet tab... I'd probably need to include an AES javascript library... I'll think about it.

The paper wallet tab would work well with a passphrase simply by appending an incrementing number to the end of the passphrase for each iteration.

Instead of sha256("my passphrase"), it would be sha256("my passphrase1")... sha256("my passphrase9999") etc.

Obviously, "my passphrase" is inappropriate as a passphrase, but is used here for clarity.

I see AES as unnecessary.  If there is a demand for an "encrypted" paper wallet (that presumably requires a memorized key), then why not just print a deterministic paper wallet with no private keys (all of which can be recreated with a memorized key).  To quell the concern that the memorized key might not have enough entropy, the paper wallet (with no private keys) could also have a single salt string printed on it, where the salt and the memorized key are required to regenerate the private keys.

[dooglus]

Of course, it's not as elegant as the feature you have described. The current functionality is one passphrase to one bitcoin address versus what you proposed sounds like one passphrase to many bitcoin addresses.

Nice workaround, but you're right; I was thinking of having the same passphrase for all the wallets on a single sheet of paper.  I want multiple addresses, and don't want to have to remember multiple passphrases for them.

Maybe it would be useful to have the option to print the same page of addresses twice - once encrypted (for my bookshelf) and once unencrypted (for the bank vault in the event that I lose the wetware copy of the passphrase).

I see AES as unnecessary.  If there is a demand for an "encrypted" paper wallet (that presumably requires a memorized key), then why not just print a deterministic paper wallet with no private keys (all of which can be recreated with a memorized key).  To quell the concern that the memorized key might not have enough entropy, the paper wallet (with no private keys) could also have a single salt string printed on it, where the salt and the memorized key are required to regenerate the private keys.

The problem I see with that approach is that if I try to redeem one of my paper wallets on a compromised machine, I lose them all, not just one.  Once you have the salt and my passphrase you have all my paper wallets.

[casascius]

The problem I see with that approach is that if I try to redeem one of my paper wallets on a compromised machine, I lose them all, not just one.  Once you have the salt and my passphrase you have all my paper wallets.

That assumes the same salt and passphrase were used to produce all your paper wallets.  If it were one salt per page, or one salt per address, that wouldn't be the case.  If each address had its own salt, and you knew that you needed to redeem salt+passphrase, then you could do that (for example) directly on MtGox (which allows redemptions of arbitrary strings as private keys, which it converts via sha256 to a 256-bit value).

[dooglus]

That assumes the same salt and passphrase were used to produce all your paper wallets.  If it were one salt per page, or one salt per address, that wouldn't be the case.  If each address had its own salt, and you knew that you needed to redeem salt+passphrase, then you could do that (for example) directly on MtGox (which allows redemptions of arbitrary strings as private keys, which it converts via sha256 to a 256-bit value).

I think I was probably using the terminology wrongly, mixing "keys" with "wallets", etc.

the paper wallet (with no private keys) could also have a single salt string printed on it, where the salt and the memorized key are required to regenerate the private keys

That's the part that made me think a single salt plus the passphrase would give up all the private keys in the wallet in one fell swoop.

But if the salt was long enough to not be brute-forceable, and each address in the wallet had its own salt, that could work nicely.

[Red Emerald]

That assumes the same salt and passphrase were used to produce all your paper wallets.  If it were one salt per page, or one salt per address, that wouldn't be the case.  If each address had its own salt, and you knew that you needed to redeem salt+passphrase, then you could do that (for example) directly on MtGox (which allows redemptions of arbitrary strings as private keys, which it converts via sha256 to a 256-bit value).

I think I was probably using the terminology wrongly, mixing "keys" with "wallets", etc.

the paper wallet (with no private keys) could also have a single salt string printed on it, where the salt and the memorized key are required to regenerate the private keys

That's the part that made me think a single salt plus the passphrase would give up all the private keys in the wallet in one fell swoop.

But if the salt was long enough to not be brute-forceable, and each address in the wallet had its own salt, that could work nicely.

If you have to have a unique salt for every address, why even bother being deterministic... That's not deterministic anymore.

I was picturing the paper wallet page having a text box at the top for a secret key.  You put that it and it encrypts all of the private keys with the same key.  This should be quite simple to do.

I would probably print one unencrypted page for a physical safe, then enter a key to encrypt all of the private keys and print that page out to keep in my desk at home.

If I use one of my paper keys on a compromised computer, I don't want to lose all of them. Non-deterministic wallets should guarantee this.

[coretechs]

Hi guys, I created a fork and branch (comp_wif) with a few changes to add support for compressed public keys.  Bitcoin 0.6+ utilizes compressed pubkeys when generating new addresses and the dumpprivkey/importprivkey commands support both formats.  Naturally I wanted my favorite bitcoin utility to support it as well.  

This is actually the first time I've used github, and it's been years since I did any java programming, but I think it was trivial enough to implement without making too much of a mess!  I really only changed the "Wallet Details" tab.  It now accepts and displays WIF keys with the compression marker and displays the corresponding compressed public key and bitcoin address.   I think I managed to avoid introducing any errors but if anyone would like to give it a second look I'd appreciate it.


Latest commit:  d2ba2803 0ebfba0b
https://github.com/coretechs/bitaddress.org/tree/comp_wif


I used the following test cases:
http://sourceforge.net/mailarchive/message.php?msg_id=28648286

[dooglus]

I don't know if this is a bug, or if I'm doing something wrong, but if I go to the wallet details tab and paste in these 64 characters as a hex private key:

> 0000111122223333444455556666777788889999AAAABBBBCCCCDDDDEEEEFFFF

then it tells me the "Private Key Base64 (44 characters):" is

> EREiIjMzRERVVWZmd3eIiJmZqqq7u8zM3d3u7v//

which is only 40 characters, not 44.

If I then try entering those 40 characters as the private key, it tells me:

> The text you entered is not a valid Private Key!

I guess because my made up 64 character hex private key started with a few zeroes.  Would this ever happen with a randomly generated key pair?

[coretechs]

Nice catch!

It looks like that bug is present in the master as well.  It's the same bug that Casascius pointed out earlier in this thread, looks like it was missed for the base64 conversion.

I added the padding to the byte array before it gets passed to bytesToBase64() and it appears to be working correctly now.

New commit: 0ebfba0b
https://github.com/coretechs/bitaddress.org/commit/0ebfba0b37d84ec5b9401df7e8f1be5c9ea4ad4b

[dooglus]

Nice catch!

It looks like that bug is present in the master as well.  It's the same bug that Casascius pointed out earlier in this thread, looks like it was missed for the base64 conversion.

I added the padding to the byte array before it gets passed to bytesToBase64() and it appears to be working correctly now.

New commit: 0ebfba0b
https://github.com/coretechs/bitaddress.org/commit/0ebfba0b37d84ec5b9401df7e8f1be5c9ea4ad4b

Yes, I didn't actually try your version.  Your post just reminded me that there was a thread about this and prompted me to report the bug.

[pointbiz]

Great work! Thank you for the contribution. I reviewed the code looks good. I have to catch up a bit on the compressed keys stuff to be 100% sure.
Thank you for the bug fix on the zero padding of base64 keys.

I will get this merged to the master branch and posted on bitaddress.org
I will post here when it's live.

[pointbiz]

v1.5
https://www.bitaddress.org/bitaddress.org-v1.5-SHA1-f2e410251c8741ac65d29a1c6fb8ef6919b6ab8b.html

Wallet Details Tab:
- coretechs fixed a bug with the display of the base64 private key
- coretechs added support for compressed public/private keys


Thanks again to coretechs for the contribution!!

[Stephen Gornick]

https://www.bitaddress.org/bitaddress.org-v1.5-SHA1-f2e410251c8741ac65d29a1c6fb8ef6919b6ab8b.html

I can verify that the site has been updated and returns the same HTML from the latest commit (e58a86a2fad0e9ac4c9530abd1035a71abbbcce7) in github.

To confirm this I first check the sha1sum hash of the html returned by a request to http://bitaddress.org:

$ wget --quiet -O - http://bitaddress.org|sha1sum
f2e410251c8741ac65d29a1c6fb8ef6919b6ab8b  -

Then from my bitaddress.org repo:

$ git rev-list --max-count=1 HEAD
e58a86a2fad0e9ac4c9530abd1035a71abbbcce7

$ sha1sum bitaddress.org.html
f2e410251c8741ac65d29a1c6fb8ef6919b6ab8b  bitaddress.org.html

[truckingeek]

Having a rather interesting issue.  About 3% of returned public addresses from the bulk wallet are one byte short.  Here's a few for your perusal:


10056,"1rbHDjLZhk6TMpqEvWnAxBKhZphKG3CMk","5KMpUJ5BNX6iLign2NLZxRBmjQ59PRdtkWYzF5PTU9aPgZsa34a"   
10071,"1b7pujCEMpkti7am7Y6Pg5f3RxGyxVN1E","5KhQv5XrFwJBoJto2LXMhLzyRjSwuJv35kXukcNEbMcD4rfRFrG"
10072,"1PHS83TkNLF2GZdDTCZp8oy91sy9i7RTL","5JakWEJ7n6pHDdCzknJbbV5Tc57abxTfAFbZkCC6iVwcrcD6jry"
10085,"1fRgmWE6g1UUYRnrfzmJ8EpnEYWGgHT9Y","5KEsH9rxEdk5DEg4zgsaTYfs3QnRRsWhZ6rQoW1riB4NHwZPcnM"
10088,"1aCtNvJwetWzceqe3PmAWifGNvEorkX5K","5KCP8JQHeTHcGxvyEWwe6pLdRgBHt5dLfa13X4evUYKdgS4UCWY"
10101,"1a1iaJc6XTnJPBaDLoda2uaa2mHvsiKxU","5JfJxsKGZMuXozKnSL7BiJmqqubGym4LbdpMUx3uJZ5E7fsZNE2"
10102,"1R38v2G5wWry6mBQ3VAKVAMn9b2nqoyUu","5JYB9naYToA7c2frKNYNV1gSMAJA8UQqb7sNdasjt1no8xGVKtd"


Not sure what's causing it...

[dooglus]

Having a rather interesting issue.  About 3% of returned public addresses from the bulk wallet are one byte short.  Here's a few for your perusal:

Some addresses are bigger than others.  It's perfectly natural, and nothing to worry about.

See https://en.bitcoin.it/wiki/Base58Check_encoding#Creating_a_Base58Check_string (particularly step 5) for the technical details as to why the length isn't fixed.

[dooglus]

The bulk wallet page says "daeman", when it should say "daemon".  See http://en.wikipedia.org/wiki/Daemon_(computing).

Also, step 5 of "How do I use a Bulk Wallet to accept Bitcoins on my website?" says "Use the original wallet file you generated in step 1", but step 1 doesn't involve making a wallet file, just a list of keys:

"Use the Bulk Wallet tab to pre-generate a large number of bitcoin addresses (10,000+). Copy and paste the generated comma separated values (CSV) list to a secure text file on your computer. Backup the file you just created to a secure location."

[truckingeek]

Thanks, I was about to manually remove the "offenders!"

[rjk]

Thanks, I was about to manually remove the "offenders!"

X-treme OCD, baby! They are all valid btw. Also, don't use the ones you posted since you were kind enough to post the private keys.