Topic: [ANN] bitaddress.org Safe JavaScript Bitcoin address/private key - page 38. (Read 153002 times)

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?

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

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.

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


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.

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).

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).


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.

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.

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.

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.

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.

+1

Encryption-protected paper wallets, excellent!

I have a feature request:

I like the idea of using a paper wallet, but I don't like that to keep funds safe I have to keep the paper somewhere inaccessible, like a bank vault.  That's inconvenient when I need access to the funds.

I'd like to be able to provide a passphrase to BitAddress, and have a sheet of paper wallets generated which have the private key encrypted using that passphrase.

Then I can keep a copy of the paper wallets in my house and not worry about having the funds stolen in the event of a burglary, since the passphrase (which is only in my head) would be needed to get at the real private key.

The 'Wallet Details' tab could then recognise when I typed in an encrypted private key and prompt for the passphrase before decrypting it and showing the same details that it currently shows.

What do you think?

Could any of this js code be used to spend a coin? Or must I use pywallet or third-party site?

A tx in js would would be nifty. Exporting a tx (via QR code) which I could then move to an insecure PC (for relay) would be neat.

Confirmed. This same behavior (Complete vs HTML Only) occurs in Chrome and IE9.

So it's best people save the "HTML Only" to disk locally so it's unmodified.

That's odd as I'm using Firefox 9.0.1 on Ubuntu. I just saved the page and then tried this.
But wait - I just tried this again. This time I noticed that Firefox has an option at the bottom for how to save. When you select "Web Page Complete" it is altered. When you choose "HTML Only" it doesn't alter and the digest is correct. The "Complete" method was default and it saved as 165745 bytes whereas the "HTML only" version is 170094 bytes.

Anyway, now I see that it works. Just have to remember to be careful about that in future.

openssl dgst -sha1 bitaddress.org-v1.4-SHA1-5c120c0860032e88a8fd81b802d6f53a5fc082bf.only.html
SHA1(bitaddress.org-v1.4-SHA1-5c120c0860032e88a8fd81b802d6f53a5fc082bf.only.html)= 5c120c0860032e88a8fd81b802d6f53a5fc082bf

Note also that if you "view source" and then save the raw text to file it also does work correctly.

Thx!

I did some investigating. If you download the file in the zip from github you should get the correct SHA1 hash of 5c120c0860032e88a8fd81b802d6f53a5fc082bf
When I downloaded the file through bitaddress.org with IE9 or Chrome those browsers saved an altered copy of the HTML. When I downloaded the file with Firefox it was saved unaltered and the SHA1 hash matched.

openssl dgst -sha1 bitaddress.org-v1.4-SHA1-5c120c0860032e88a8fd81b802d6f53a5fc082bf.html
SHA1(bitaddress.org-v1.4-SHA1-5c120c0860032e88a8fd81b802d6f53a5fc082bf.html)= e7c3f3f47c6bbe4a130412b45e974fc8e83510dc

I must be doing it wrong?

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

v1.4
 - Wallet Details Tab: Allow for a deterministic wallet to be created by entering a passphrase on
   the wallet details tab. If you input text that is not a valid private key you will
   be prompted and asked if you want to use the entered text as a passphrase to
   create a private key. If you select OK then it will perform a SHA256 of the passphrase
   to generate your private key.
 - Wallet Details Tab: Added QRCodes. Added Public Key.
 - Bulk Wallet Tab: added FAQs.
 - Version number now shown in footer.

Bruce Wagner of The Bitcoin Show has produced a video on securing your bitcoin and he recommends using paper wallets generated with bitaddress.org

http://onlyonetv.com/2011/12/security-for-your-bitcoin-the-bitcoin-show/