Bitcoin Forum
December 08, 2016, 02:26:11 AM *
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 110073 times)
pointbiz
Sr. Member
****
Offline Offline

Activity: 426

1ninja


View Profile
September 23, 2011, 01:44:46 AM
 #81

v0.7
http://www.bitaddress.org/bitaddress.org-v0.7-SHA1-34e344a0d229dc10c8f5c99ed6b6298e6fc5e39f.html
 -Added Bulk Wallet tab. Now you can generate CSV lists of addresses!

Use-case: Generate lists of wallets you will copy/paste to an encrypted location. Could be very useful for merchants in conjunction with a service like bitcoinnotify.com

Another use is a multi page wallet. With Chrome you can drag the text area down and print as many pages as you'd like.

Example:

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

Posts: 1481163971

View Profile Personal Message (Offline)

Ignore
1481163971
Reply with quote  #2

1481163971
Report to moderator
Even in the event that an attacker gains more than 50% of the network's computational power, only transactions sent by the attacker could be reversed or double-spent. The network would not be destroyed.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481163971
Hero Member
*
Offline Offline

Posts: 1481163971

View Profile Personal Message (Offline)

Ignore
1481163971
Reply with quote  #2

1481163971
Report to moderator
1481163971
Hero Member
*
Offline Offline

Posts: 1481163971

View Profile Personal Message (Offline)

Ignore
1481163971
Reply with quote  #2

1481163971
Report to moderator
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784


firstbits:1MinerQ


View Profile WWW
September 23, 2011, 02:11:25 AM
 #82

That's excellent and I could see that being useful.

(Maybe you could add

.menu .tab { cursor:pointer }

to the css so the tabs get a finger pointer instead of a caret... just a bit nicer.
I tested this here with FireBug)

casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


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


View Profile WWW
September 23, 2011, 03:18:15 AM
 #83

Sweet CSV option!  Suggestion, put doublequotes around strings so applications interpret them as text rather than trying to parse them as numbers (and choking on the letters). The index should remain unquoted.

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

Activity: 426

1ninja


View Profile
September 23, 2011, 03:49:36 AM
 #84

v0.8
http://www.bitaddress.org/bitaddress.org-v0.8-SHA1-47b989b8a33407df14d21dbd00fad653e0161d6c.html
 -Css update to tabs
 -Added double quotes around CSV bitcoin address and private key output

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

Activity: 602


View Profile
September 23, 2011, 03:52:27 AM
 #85

Great work  Cool
Jan
Legendary
*
Offline Offline

Activity: 1042



View Profile
September 23, 2011, 06:17:41 PM
 #86


The attacker would not search for the private keys alone, he would calculate the private/public key and their corresponding address for all passwords up to a certain length (depending on his capacity), and store them in a table. Then he would scan incoming blocks for transactions that send coins to addresses that match his table. This allows him to harvest transaction outputs sending coins to addresses based on private keys that are generated on weak passwords. With one such table he can attack everyone using this scheme in parallel.
If the key generation is based on both a password and something that is globally unique (such as an email address) the attacker will have to either calculate really really big tables (unfeasible) or make a targeted attack against a single user (provided that he knows his email address), yielding much less profit.


How much of a length do you have in mind?  The deterministic generators in existence now and that are proposed require passphrases with a minimum of 20-30 characters... this guy's table would have to have something like 10^37 entries, and he would need in excess of the world's capacity in hard drives to store it.  

The post I referenced originally mentioned 5 characters, which makes a rainbow attack trivial:

Consider these two possible wallet decisions:
1) using a 5-character password to create a Deterministic Wallet using some tool.
2) create a truly random private key and copy/paste it into a text file in an encrypted true crypt drive, that is protected with a 5-character password, that you back up in several locations online and offline.


In addition, calculating ECDSA public/private keys is already a very slow operation, he would probably need in excess of his lifetime to produce just 10^20 keypairs and the GDP of a small country just to pay for the electricity, let alone 10^37.  This attack is effective against the fool who chooses "john's bitcoins" as his passphrase, but not against someone who uses a program that refuses to cooperate with a poor passphrase.
Creating a keypair is not computationally hard and can be implemented effectively and cheaply in hardware.
For long passwords the attack can be turned around by making a table of all addresses in use and continously guessing at passwords.

Quote
Although I agree that the linked wiki article discusses it and recommends the user enter a "salt"... what practical difference would there be between the user entering a "salt" into a separate field, versus simply appending some extra characters to their passphrase?  They will be concatenated anyway, so none from what I can tell.  Salt in most other contexts is not something chosen by a user, rather it is something added by an application outside the user's control.

They aren't really concatenated, but seperate inputs to scrypt, which generates the seed used for deriving keys. The idea with the salt is that it is easy to remember, unique, and not a secret.  In practical terms it allows for stronger security without having the user remember/keep-secret a longer password. In a UI I would always keep this as two seperate fields, as this makes it easier for the user to understand that there is a secret component and a unique component of his wallet.

With deterministic wallets we cannot rely on a central component generating the salt. We need the salt to be the same whenever we wish to recreate the wallet.


I still don't get it.  One component needs to be secret (but not unique) and the other needs to be unique (not secret)?

The whole point of a passphrase is to be both unique and secret.  If they're both, and they're long enough (entropy wise) that's all that's needed.
We want normal people to use Bitcoin. Asking the average Joe to memorize a complex 30 character password is error prone and will surely result in many lost wallets. The whole point of the salt and scrypt is that you can do with a shorter password that is easier to remember.

We make a rainbow attack unfeasible by using a unique salt that is easy to remember instead of a very long password.
We can make a direct brute force attack against a single wallet (where the salt is known) unfeasible by making each brute force attempt computationally hard. Scrypt achieves this both for software and hardware implementations. So basically we can reduce the password length by requireing the user's software to spend CPU during initialization.

If we make sure that brute forcing the private key from password is computationally as hard as brute forcing the private key from a public key we have something that is as safe as the Bitcoin system.

This completely makes sense in the context of using scrypt on, say, a website where there's a database, and per-user salt is stored separately from the user's brain.  If scrypt is the algorithm of choice, and the algorithm wants a salt, and the user has to remember it, why not just define the first n characters of the passphrase (or the hash of it) and call it the "salt", rather than burden the user with caring about the difference.  By demanding that the user understand "salt" to use a payment system, the size of the potential audience willing to use the payment system just gets quartered or worse.
The UI will be simple. "Enter your password" "Enter your email address". The CPU demanding calculation is only done when you wish to create/re-create your wallet.


Mycelium let's you hold your private keys private.
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


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


View Profile WWW
September 23, 2011, 07:09:17 PM
 #87

The UI will be simple. "Enter your password" "Enter your email address". The CPU demanding calculation is only done when you wish to create/re-create your wallet.

And I assume e-mail address is used as the salt?  I would probably agree that would be joe-friendly and work as a salt.


The post I referenced originally mentioned 5 characters, which makes a rainbow attack trivial:

I am not sure he seriously intended to mean that people should choose 5 character passwords.

Creating a keypair is not computationally hard and can be implemented effectively and cheaply in hardware.

I'm not saying it's hard, I'm just saying it's very slow compared to (as an example) hashing.  It won't stop the attack, but it will slow it enough to make a difference.

For long passwords the attack can be turned around by making a table of all addresses in use and continously guessing at passwords.

For appropriately long passwords, that attack is unlikely to yield any results within the span of the attacker's lifetime.

We want normal people to use Bitcoin. Asking the average Joe to memorize a complex 30 character password is error prone and will surely result in many lost wallets. The whole point of the salt and scrypt is that you can do with a shorter password that is easier to remember.

A 30 character password need not be complex to be secure.  "Stinklers in the pie--with guymonds" would be just as memorable as "Fxh00w3e" without being short.  I would think that a password like this should be written down and kept in a safe place where joe's next of kin will find it if necessary.  Since it won't be used regularly, joe won't have the benefit of needing to recall it daily - which would help him remember it - like he would with other passwords.

I will definitely agree with you that the benefit of having a computationally expensive algorithm like scrypt is clearly beneficial, and that having the user provide his e-mail address (or any other non-secret datum he is unlikely to forget or confuse) as salt is an excellent user-friendly idea.


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

Activity: 426

1ninja


View Profile
September 24, 2011, 12:34:39 AM
 #88


The post I referenced originally mentioned 5 characters, which makes a rainbow attack trivial:

I am not sure he seriously intended to mean that people should choose 5 character passwords.


I mentioned 5 characters to highlight the point that if something is weakly encrypted it is much safer on your computer then publicly brute force-able in the block chain.

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
September 27, 2011, 12:54:57 AM
 #89

SSL now available:
https://www.bitaddress.org/bitaddress.org-v0.8-SHA1-47b989b8a33407df14d21dbd00fad653e0161d6c.html

Now you can browse via HTTPS this is to mitigate a man-in-the-middle attack.


I moved my hosting to a place where I can host it and pay for the SSL certificate with Bitcoins. Thanks again to those who have donated. Your BTC went to help with the hosting costs!!

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
September 27, 2011, 05:06:37 PM
 #90

I am planning on donating another 5 BTC if you can modify it so you can enter the number of QR-code-pairs on a page just like on the CSV, rather than having just one.  And also, are you releasing this as open source?  If so, can you add a licensing header in the comments?

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

Activity: 271


View Profile
September 27, 2011, 06:53:54 PM
 #91

I think that just means pywallet can't do transactions, but can still import/export addresses just fine.
pointbiz
Sr. Member
****
Offline Offline

Activity: 426

1ninja


View Profile
September 28, 2011, 03:43:39 AM
 #92

I am planning on donating another 5 BTC if you can modify it so you can enter the number of QR-code-pairs on a page just like on the CSV, rather than having just one.  And also, are you releasing this as open source?  If so, can you add a licensing header in the comments?

I will take you up on that offer... I will call that feature 'Multi Wallet' or 'Paper Wallet' and it will be the next item on my TODO list.

Should the user enter the: 
1) number of QR-code-pairs ?  OR
2) number of QR-code-pairs per page and number of pages?  OR
3) number of pages ?

It looks like roughly 5 or 6 QR-code-pairs would fit on one page assuming they are the same height as used in the Single Wallet.

You mentioned previously about leaving space to write what each wallet is used for. In the Single Wallet design there is one line of space between the btc address and the private key. Lets call the QR-code-pair a 'box'. I thought it's more appropriate to write inside each box but let me know if you think the space between the btc address and private key should be reduced in favor of vertical space between the multiple 'boxes'.

Regarding, open sourcing the code... I had not really thought about it, for now I'll say no but I'll reconsider in the future if there's a compelling reason. With that being said, the most useful and reusable parts of the code ARE open source. I will provide a comment at the top of the page to help clarify the licensing situation.

Here is a summary of the JavaScript functions used in the code that have a redistributable license:
Code:
JavaScript function License
------------------- --------------
Array.prototype.map Public Domain
window.Crypto BSD License
window.SecureRandom BSD License
window.EllipticCurve BSD License
window.BigInteger BSD License
window.QRCode MIT License
            
I don't know what the license information is for the window.Bitcoin function as that information is not available on github for bitcoinjs-lib. The only thing modified in the window.Bitcoin function is the addition of the sipa private key wallet import format which I have offered to Stephan Thomas to add into the bitcoinjs-lib.


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
September 28, 2011, 04:48:02 AM
 #93

I would suggest you just let someone set the number of codes and not worry about pagination.  lots of browsers, lots of page sizes, lots of ways to cause unintended side effects, it is well within right to leave page setup to the user.

Yes space to write is good. Just the format you have now is great. Six to a page is plenty.  I have already used your site to make a QR paperwallet I am actively using. (got a USB QR code scanner and am enjoying using it.)

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.
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2002



View Profile
October 01, 2011, 06:54:24 PM
 #94

There is a forum post reporting a problem sending from a v0.3.2x client to "any address generated by BitcoinAddress".

I don't have v0.3.2x anymore to test.  Would someone be able to provide a response:
 - http://bitcointalk.org/index.php?topic=46355.msg553309#msg553309

Stephen Gornick
Legendary
*
Offline Offline

Activity: 2002



View Profile
October 02, 2011, 03:04:44 AM
 #95

I don't have v0.3.2x anymore to test.  Would someone be able to provide a response:

Hm, looks like actually the problem being reported is with v0.3.19.  Would be a problem for BitAddress even if it is that older version.  Can anyone else confirm either way? 
 - http://bitcointalk.org/index.php?topic=46355.msg553631#msg553631

casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


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


View Profile WWW
October 02, 2011, 03:23:54 AM
 #96

I doubt that the problem is with BitAddress.  I see it as more likely that some junk ended up on the clipboard (like a trailing space) that the old Bitcoin client didn't trim out.

I verified tons (10,000+) of addresses generated by BitAddress for validity independently using a Windows-based script I wrote.  Not once did BitAddress issue a non-well-formed Bitcoin address, even in the older versions afflicted by bugs affecting the private key.

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

Activity: 426

1ninja


View Profile
October 02, 2011, 04:22:51 AM
 #97

BlockExplorer shows that it's a valid Bitcoin Address:
http://blockexplorer.com/q/checkaddress/1PyrrD1EnHminnFPipPGyve4HiVyJPKmGy

I tried installing v0.3.19 to test but I could not get that version to run on Windows 7.

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

Activity: 406


View Profile
October 02, 2011, 04:26:38 AM
 #98

Nice work!
pointbiz
Sr. Member
****
Offline Offline

Activity: 426

1ninja


View Profile
October 02, 2011, 05:41:38 AM
 #99

Cusipzzz confirmed he could sent 0.02 BTC to the address provided by jago25_98 in the other thread.
https://bitcointalk.org/index.php?topic=46355.msg553869#msg553869

So I consider the case closed. Looks like the issue the guy had in the other thread was that he could not send 0.0001 BTC from the v0.3.19 client and that is because the transaction fee was 0.01 BTC in that version, and he tried to send an amount less than the transaction fee and the daemon gave him an incorrect error message. He didn't have issues with the v0.4.0 version because the transaction fee is now reduced to 0.0001.

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
October 03, 2011, 12:26:36 AM
 #100

v0.9
https://www.bitaddress.org/bitaddress.org-v0.9-SHA1-aa61ca480288e1bda00f1f042d60a057880a2321.html

-Added more entropy, all mouse movements in the window will add to the random seed pool.
-Added PaperWallet tab. You can now generate multiple QRCode pairs per page.

Coder of: https://www.bitaddress.org      Thread
Open Source JavaScript Client-Side Bitcoin Wallet Generator
Donations: 1NiNja1bUmhSoTXozBRBEtR8LeF9TGbZBN   PGP
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!