Bitcoin Forum
December 08, 2016, 04:32:46 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 »
  Print  
Author Topic: [ANN] bitaddress.org Safe JavaScript Bitcoin address/private key  (Read 110089 times)
osmosis
Sr. Member
****
Offline Offline

Activity: 301



View Profile
February 15, 2012, 10:35:02 PM
 #161



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.
1481214766
Hero Member
*
Offline Offline

Posts: 1481214766

View Profile Personal Message (Offline)

Ignore
1481214766
Reply with quote  #2

1481214766
Report to moderator
1481214766
Hero Member
*
Offline Offline

Posts: 1481214766

View Profile Personal Message (Offline)

Ignore
1481214766
Reply with quote  #2

1481214766
Report to moderator
1481214766
Hero Member
*
Offline Offline

Posts: 1481214766

View Profile Personal Message (Offline)

Ignore
1481214766
Reply with quote  #2

1481214766
Report to moderator
"Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
February 16, 2012, 12:19:57 AM
 #162

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
Sr. Member
****
Offline Offline

Activity: 426

1ninja


View Profile
February 16, 2012, 02:08:41 AM
 #163


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.

Coder of: https://www.bitaddress.org      Thread
Open Source JavaScript Client-Side Bitcoin Wallet Generator
Donations: 1NiNja1bUmhSoTXozBRBEtR8LeF9TGbZBN   PGP
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 16, 2012, 02:28:05 AM
 #164

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.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
February 16, 2012, 02:35:43 AM
 #165

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
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 16, 2012, 03:20:50 AM
 #166

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

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
February 16, 2012, 03:37:32 AM
 #167

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.

Quote
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
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
February 16, 2012, 07:19:42 PM
 #168

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.

Quote
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
Donator
Sr. Member
*
Offline Offline

Activity: 362



View Profile
March 11, 2012, 03:22:59 AM
 #169

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

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

http://bitcoindoc.com - The Rise and Rise of Bitcoin | http://nxtportal.org - Nxt blockchain explorer
dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
March 11, 2012, 05:11:27 AM
 #170

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
Donator
Sr. Member
*
Offline Offline

Activity: 362



View Profile
March 11, 2012, 06:57:22 AM
 #171

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

http://bitcoindoc.com - The Rise and Rise of Bitcoin | http://nxtportal.org - Nxt blockchain explorer
dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
March 11, 2012, 06:59:34 AM
 #172

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
Sr. Member
****
Offline Offline

Activity: 426

1ninja


View Profile
March 13, 2012, 03:31:44 AM
 #173

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.


Coder of: https://www.bitaddress.org      Thread
Open Source JavaScript Client-Side Bitcoin Wallet Generator
Donations: 1NiNja1bUmhSoTXozBRBEtR8LeF9TGbZBN   PGP
pointbiz
Sr. Member
****
Offline Offline

Activity: 426

1ninja


View Profile
March 23, 2012, 01:53:19 AM
 #174

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!!

Coder of: https://www.bitaddress.org      Thread
Open Source JavaScript Client-Side Bitcoin Wallet Generator
Donations: 1NiNja1bUmhSoTXozBRBEtR8LeF9TGbZBN   PGP
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2002



View Profile
March 23, 2012, 07:46:19 AM
 #175


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
Jr. Member
*
Offline Offline

Activity: 34


View Profile
March 27, 2012, 09:46:03 PM
 #176

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

If this post totally rocked your socks, you can donate to1BEoHyMZ3VmFiQiFAaw3iAdNT6Zdjdp1Rm
dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
March 27, 2012, 11:55:24 PM
 #177

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
Legendary
*
Offline Offline

Activity: 2002



View Profile
March 28, 2012, 12:41:24 AM
 #178

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:

Quote
"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
Jr. Member
*
Offline Offline

Activity: 34


View Profile
March 28, 2012, 01:32:30 AM
 #179

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

If this post totally rocked your socks, you can donate to1BEoHyMZ3VmFiQiFAaw3iAdNT6Zdjdp1Rm
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
March 28, 2012, 01:35:58 AM
 #180

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

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!