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

Hi pointbiz,

Thanks for reply.
It's true that deterministic wallet is not as secure as truly random private key. But for most common people who do not take care their bitcoin every day, I would say that current wallet is not a good idea. I have convinced 3 of my friends to get some bitcoins, only the one  who meet me everyday have his coins now, the other two both lost their wallets. I think the lost of wallet is a very common issue for not deepin users.

5-character password is too easy to guess out. May be you can add  some suggestions on you website, like 8+ characters, do not use alphabet only string...  A support of utf-8 character would also be a good idea, it is easy to make a exhaustive key search of 5 characters combination from 128 ASCIIs but it is impossible to look through 5 characters combination of utf-8 set.

I wrote a deterministic wallet generator for Casascius Bitcoin Utility.  Here are my thoughts.

My utility pre-fills the passphrase field with randomized alphabetic characters as a default.  If the user doesn't care, the alphabetic characters suffice.  The Microsoft .NET framework offers a RNG specifically suited for cryptographic functions, and this is the source of the entropy for this random passphrase.  Chances are decent that it's a good one.

If the user chooses a short passphrase, I warn him persistently about why that's a problem.  I recommend to him that he simply mash keys into the text box if he must not accept the default.  I don't remember the precise rules, but I require either 30+ characters of any type, or 20+ characters with at least two of each of three classes (uppercase, lowercase, numbers, and symbols).

A deterministic generation function does one more very valuable thing from an auditability perspective that has nothing to do with recreating wallets.  Supporting deterministic generation from a passphrase allows the average user to control for the possibility that the RNG in your generator isn't rigged or flawed in a non-obvious manner.  If your RNG turns out to be flawed at any time down the road, it would turn into a huge liability for anyone who has ever used your generator.  (Google "Debian OpenSSL key flaw" for an example of a past occurrence of this mess). On the other hand, if it produces the same deterministic wallet as any other program made for the same purpose, it can be conclusively deemed to operate as advertised.

I'll say maybe. I'm trying to keep the interface simple, maybe an advanced tab or something would work for that.

At the moment I'm not convinced Deterministic Wallets are the way to go. People think alike and therefore the algorithms and patterns used to make Deterministic Wallets can be gamed en mass.

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 scenario #1 someone can turn their GPU farm to silently create a bunch of Deterministic Wallets and check them against the blockchain. Only 1 person has to have an easy password for this attack to work and it's more likely to be a profitable attack.

In scenario #2 someone has to personally hack you then make childs play of your password. Much less likely to happen and more expensive for an attacker. Your 5-character password is much safer on your computer or on dropbox then in the blockchain for anyone to brute force. Maybe I could enforce a minimum password size and minimum complexity.

All that being said thank you for the suggestion, I see there will probably be demand for this type of feature. It's definitely a complimentary feature that would make sense on bitaddress so I'll consider it in the future.

request for QR code to give balance from blockexplorer: https://blockexplorer.com/q/addressbalance/

The attack vector scenarios are a bit complicated, this makes it difficult for me to provide instructions that are practical, user friendly and good security advice. So, I'll focus on the code first then try and give people reasonable instructions.

Booting from a LiveOS is always safer. I believe a trojan that just logs keys would not be a threat, if you use bitaddress.org as a paper wallet.
If you use bitaddress.org to copy/paste the address into a TrueCrypt drive then you would still be at risk of your TrueCrypt password being logged.

A trojan that takes screenshots, reads directly from memory or one that monitors data sent to a printer would still be a threat.

bitaddress.org reduces your risk of installing a trojan since there is nothing to install. I think that is important to note.

I'm leaving the redeeming problem to others, I figure the sipa private key import patch for bitcoin will probably make it into the official build at some point because there is so much demand.

If you plan to completely clear out an address and never use it again then this tool, by Joric, is useful:
https://bitcointools.appspot.com/
It uploads your private key to the server and returns you a wallet.dat file you can use with the bitcoin client.

EDIT: However, pyWallet is probably the best option since you don't have to trust an online service.

Thanks again for the link. I took a look and the jQuery plugin is just a wrapper for an independent QR code library, therefore I don't need to worry about requiring jQuery! So, I'm adding the QR code functionality to my to do list.
http://d-project.googlecode.com/svn/trunk/misc/qrcode/js/qrcode.js

Hi pointbiz,

I noticed that there are a lot of people that think about virtual wallet that no data needed to save in local or other server. The best way to do this is to specify a memorizable but not easy to guess string by the end user and the string can be used to generate private/public key pair.  When the user want to know his/her private/public key pair, he/she can generate them again with the same string.

Can you consider about that function in your website?

* Possible yes, I would agree with you: use a live OS, however there's no reason to use LinuxCoin specifically for opening a browser, any common distro would do.

* With the current official client/daemon, you can't import private keys.

You can use Pywallet

Is it still possible that there could be a keylogger performing screenshots even when not even connected to the Internet (but will upload the screenshots once the connection is re-established?)

To use this even more securely would it not make sense to boot to a LiveOS (e.g., LinuxCoin, or Ubuntu even) that is not connected to the internet even and then load the page from the usb flash drive, for instance?
 - http://en.bitcoin.it/wiki/LinuxCoin

And secondly, just to make sure I'm current on this -- there is no way for these to be redeemed without first downloading a patch for bitcoind that will allow importing of the key?
 

I like it if it is what I think it is...

how would one go about using this?

excellent policy, the thorough commenting makes the code much easier to review.

The intention of the site is to always provide a single .html file. So there will never be externally included/linked files. I also will not include any minified JavaScript. jQuery could be embedded like the other JavaScript but it would be a huge bulk, so I'll be investigating doing the QR code without the jQuery dependency.

Good idea regarding the media types.

Cheers.

You're welcome.  You are doing good work.

If you tag the instructions with a CSS style marked with "@media screen" and "@media print" (see http://www.w3.org/TR/CSS2/media.html), you can control what appears on screen versus what's printed.  So that way the printout can omit the instructions, fit within a single page, giving just the addresses and (ideally) a space for the user to write notes next to each address to record what he used it for.

Thanks SO much for the donation Adds a lot of excitement to the fun for me!

I noticed there is some extra space left to fill for an 8.5x11 inch print out. I'm thinking about your two suggestions... the instructions and/or more than 1 address generated.

You probably could formulate a QR code in javascript.  There's a lightweight C library out there that's very simple, and given a string, returns an array of integers - one per pixel - to say what needs to be white and black.  This could be converted to javascript.  I would strongly favor avoiding jQuery, or any included or linked files whatsoever for that matter.  Ideally one should be able to just save the single .html file to disk and generate fresh bitcoin addresses with it.

That said, even if you do this, if the QR code turns out to be bulky you ought to offer both versions, so the person who wants to review the code but who isn't interested in QR codes has less to review.

nhodges, thanks for the post on the BTCNN:
http://www.btcnn.com/2011/09/bit-address-makes-offline-wallets-easy.html

nibor, thanks for the link. I know the QR code would be useful for the public key. Is it also useful to have it for the private key?
I'll dig into that jQuery QR plugin code. I'm trying to avoid having to use jQuery (because it has XMLHttpRequest in it) and it's a lot of extra JavaScript for people to review.

Very nice!

If you make it so you can click a button and see 10 addresses instead of 1 (or however many might fit on a piece of paper), then now you have a working Paper Wallet generator.  Though a paper wallet with 1 address is still just as safe and useful.

Also you might want to have something help produce entropy.  It looks like there is a "sr.seedtime" you can be calling that will take entropy from the timing of events.  If various objects called this onmouseover and onmouseout, the user could be adding entropy just by hovering towards the buttons.  EDIT: I just noticed you added it to the body tag.

Thanks for producing this.  I sent you a 10 BTC donation to your firstbits.

Great!

Just need to add the QR Codes for them all and is perfect!

https://github.com/jeromeetienne/jquery-qrcode#readme