Topic: [ANN] bitaddress.org Safe JavaScript Bitcoin address/private key - page 42. (Read 153371 times)
September 27, 2011, 12:06:37 PM
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?
September 26, 2011, 07:54:57 PM
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!!
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!!
September 23, 2011, 07:34:39 PM
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.
September 23, 2011, 02:09:17 PM
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.
September 23, 2011, 01:17:41 PM
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.
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.
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 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. September 22, 2011, 10:52:27 PM
Great work 
September 22, 2011, 10:49:36 PM
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
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
September 22, 2011, 10:18:15 PM
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.
September 22, 2011, 09:11:25 PM
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)
(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)
September 22, 2011, 08:44:46 PM
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:
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:
September 22, 2011, 05:55:52 PM
Love your program. Sent you a small donation.
Question: do you have any idea why it is that when I print the paper copy of the key pair from IE the QR codes do not print but when I print from Safari the QR codes do print (other than Microsoft sucks)?
Question: do you have any idea why it is that when I print the paper copy of the key pair from IE the QR codes do not print but when I print from Safari the QR codes do print (other than Microsoft sucks)?
Thanks for the donation!
Regarding IE8 it is as Casascius has described. I figured if I could show the QR Code in IE8 then one day I'd figure out how to print it. Thankfully Casascius has found an immediate solution. I may try putting characters in each TD tag with a really small font but I don't think the quality of the QRCode would be as good as clicking that option in the "Page Setup" of the Print Preview screen in IE8.
September 22, 2011, 02:16:44 PM
I just discovered something that I hope will make it print.
My understanding is that the QR code on IE8 is formed by creating a table full of little cells and setting their background colors to white or black.
IE does not normally print the background color of table cells on printers. But there is a checkbox in Page Setup that turns this on. Check the box. Try it again.
My understanding is that the QR code on IE8 is formed by creating a table full of little cells and setting their background colors to white or black.
IE does not normally print the background color of table cells on printers. But there is a checkbox in Page Setup that turns this on. Check the box. Try it again.
September 22, 2011, 12:19:22 PM
Love your program. Sent you a small donation.
Question: do you have any idea why it is that when I print the paper copy of the key pair from IE the QR codes do not print but when I print from Safari the QR codes do print (other than Microsoft sucks)?
Question: do you have any idea why it is that when I print the paper copy of the key pair from IE the QR codes do not print but when I print from Safari the QR codes do print (other than Microsoft sucks)?
Yes, his source code acknowledges that problem. On IE (just IE8?) the browser apparently does not support a "canvas object" which is necessary for the Javascript to render a printable image so he uses a hack that makes it work on screen but not in print.
September 22, 2011, 12:13:31 PM
Love your program. Sent you a small donation.
Question: do you have any idea why it is that when I print the paper copy of the key pair from IE the QR codes do not print but when I print from Safari the QR codes do print (other than Microsoft sucks)?
Question: do you have any idea why it is that when I print the paper copy of the key pair from IE the QR codes do not print but when I print from Safari the QR codes do print (other than Microsoft sucks)?
September 22, 2011, 11:52:20 AM
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. 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.
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.
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.
September 22, 2011, 04:57:07 AM
I am not sure this applies in this case. Rainbow attacks help attackers take a large number of hashes and try to recover plaintext from as many as possible with the same effort. In wallet generation, the hashes are used as private keys which the attacker has no access to (or else if he gets the private keys, his attack has already succeeded, there's no value in recovering the plaintext itself). This advice is useful for someone operating a website and storing hashed passwords in a database, but I believe it has no application for wallet generation.
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.
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.
September 21, 2011, 11:51:05 PM
It could either generate a raw signed transaction text that you can copy and import into a client (so you don't need to expose the key), or if connected it could inject the transaction into the network. I'm not sure how much code that part would require or whether JS can handle it, but offhand it seems feasible. Or maybe it needs a server to inject the raw trx data? If there is change then either it would have to return it to the same address or you give it another address to send to.
This would work, the only thing you would need is a way to know which available transactions were "out there" on the block chain to be spent. Some sort of webservice would need to answer that, or that would have to be provided somehow through a sort of ugly copy-n-paste of base64 data or something.
If that webservice took ajax calls, and also took ajax calls asking it to drop transactions on the network, then YES a fully functional paper wallet bitcoin client could be implemented in javascript alone.
September 21, 2011, 11:39:58 PM
Wouldn't it be really handy if you could broadcast a transaction with your page too?
I'm just thinking it's the only part missing to go full circle. We can create an address+key here. We can receive payments to it since we don't need a client running for that.
Rather than importing the key into a client and sending coins couldn't you have a small form where you enter an address and amount, paste your key and it will create the signed transaction.
It could either generate a raw signed transaction text that you can copy and import into a client (so you don't need to expose the key), or if connected it could inject the transaction into the network. I'm not sure how much code that part would require or whether JS can handle it, but offhand it seems feasible. Or maybe it needs a server to inject the raw trx data? If there is change then either it would have to return it to the same address or you give it another address to send to.
With that capability I think you would have a fully functional paper wallet system.
I'm just thinking it's the only part missing to go full circle. We can create an address+key here. We can receive payments to it since we don't need a client running for that.
Rather than importing the key into a client and sending coins couldn't you have a small form where you enter an address and amount, paste your key and it will create the signed transaction.
It could either generate a raw signed transaction text that you can copy and import into a client (so you don't need to expose the key), or if connected it could inject the transaction into the network. I'm not sure how much code that part would require or whether JS can handle it, but offhand it seems feasible. Or maybe it needs a server to inject the raw trx data? If there is change then either it would have to return it to the same address or you give it another address to send to.
With that capability I think you would have a fully functional paper wallet system.
September 21, 2011, 08:37:44 PM
Actually I am not using an iPhone. It's a 2G iPod Touch with iOS 4.2.1 (so yes, it is a slow device).
I'm glad Casascius can generate on his iPhone4. Unfortunately for my device and yours we are pretty much out of luck.
There is a technique to use setTimeout to split up the JavaScript work into batches so it doesn't trigger a browser timeout (for desktop browsers usually you get a popup asking if you want to stop the script or wait). This technique is useful when you can do bulk processing but it's not wise to implement this technique to facilitate 1 address generation because the execution path and variable scopes change when you call setTimeout.
It's mentioned here in the top answer:
http://stackoverflow.com/questions/4402012/avoiding-timeouts-on-iphone
I think the part of the code that, if divided, would yield the maximum sliceability of the workload, is the function ec.PointFp.prototype.multiply. It contains a loop that repeatedly calls an add and a twice function. I would be willing to bet that if you refactored this code so that it did 1 iteration of this loop per time slice, you could get each of the time slices small enough to run on slower devices.
This code gets reached in the part where the private key is being turned into a public key.
So if you were to timeslice it out, here's how it might work. Click the New Address button, and you generate the private key and then you globalize all the variables maintained by the slow multiply function (e, h, neg, R, i). Each time slice, you do one iteration of its loop. On the timeslice where the looping condition is no longer met, you have the return value R, which you feed into Bitcoin.Address(Bitcoin.Util.sha256ripe160(R)) and display everything. Ungrey the button. Voila
FYI a large amount of this code is unreferenced and unneeded. There's references to many unneeded curves (the only one needed is secp256k1) and there are numerous elliptic curve functions that are not needed (the only one I believe is needed is multiply plus its dependencies). All of the EC methods ending in "2D" can go as well, without impact to functionality.
September 21, 2011, 07:18:18 PM
Stephen Gornick, very interesting idea. Thank you for describing the use-case so well.
I'm going to put some tabs on the user interface to accommodate designs for different use-cases.
The first two tabs will likely be:
1) Single Wallet: what exists now on the site. Use-case: Easy wallet... introduction for new users. Disposable wallet/Instant wallet.
2) Bulk Wallet: a way to generate a CSV list of addresses. Use-case: bulk generation for use with BitcoinNotify.com
Possible other tabs include:
Multi Wallet: like Single Wallet but with 5 or 6 to fill a whole page.
Merchant Wallet: Checks and Masters as described by Stephen Gornick.
I'm going to put some tabs on the user interface to accommodate designs for different use-cases.
The first two tabs will likely be:
1) Single Wallet: what exists now on the site. Use-case: Easy wallet... introduction for new users. Disposable wallet/Instant wallet.
2) Bulk Wallet: a way to generate a CSV list of addresses. Use-case: bulk generation for use with BitcoinNotify.com
Possible other tabs include:
Multi Wallet: like Single Wallet but with 5 or 6 to fill a whole page.
Merchant Wallet: Checks and Masters as described by Stephen Gornick.
Jump to: