|
Given that doing it purely by hand is practically unfeasible, how about this as a next best option: using our NoBrainr python script (only 25-30 lines of code) on an offline raspberry pi? This can be used with or without dice.
|
|
|
|
Ah to buy an extra computer, which is never connected to the internet. Very user friendly? What's wrong with a brain wallet? I generated with a safe password a bitcoin address and store that address with private key in an text file in an truecrypt container on an USB (on 2 USBs) - with the downloaded bitaddress.org.html.
What I did:
- downloaded bitaddress.org.html
- shut down internet connection
- think about a good, strong password, which is easy to remember (first letters of your all time favarite song)
...
Please. This is extremely insecure. Attackers are using huge databases including any song titles, initials, lyrics, or exotic poems that you might think of. If you really want to go with a "brainwallet" make sure to generate one with provably sufficient entropy. How do you do that? Use NoBrainr, for instance: only 30 lines of code so very easy to review, very robust, and runs 100% locally. Main thread is at https://bitcointalk.org/index.php?topic=308972.0 |
|
|
|
We have just added a paranoid mode to NoBrainr, to generate strong cold storage addresses without relying on the system RNG at all  |
|
|
|
|
Hey, you may want to check out version 1.052 which we have just released, as it provides easy support for regular dice as a physical randomness source.
Also, I've just made a small Unix tarball available of it on the website, which provides a fully self-contained package, including ecdsa.
|
|
|
|
OK, version 1.052 is out, which has a much-improved dictionary (again!) and adds support for one of the cheapest forms of physical randomness available: dice! This is the simplest way to apply the diceware method to bitcoin address generation and be totally free of any potentially backdoored RNG. Required equipment: Six Five regular dice. Or, just one, but five is much more fun, really To generate a secure storage address using dice, simply throw them and record the result on the NoBrainr command line as shown below. 5 throws yield a word. Example of a 90-bit strong (seven words) address generated by throwing dice: 07/11/2013 15:29:32.27> nb_create 35412 13263 66533 45163 13165 41255 62216
18FmQmp5EezkXUv22ZY2PeCpsdAuN1aGV1 == knobs bands future pens bacon aliens unix
Another example: this one's a ridiculously strong 130-bit (10 words) address: Thu 11/07/2013 21:36:21.37> nb_create 23541 25631 55422 25321 56411 53151 42323 55221 16246 52131
1FkDV5eRKsoaQfbtb32rfsLLoTWZ1BWjff == duly flop store fennel tear seems mixes 789 ssd roomy
Enjoy! It would be nice if somebody could make a little video tutorial, or blog post out of this at some point  PS: GPG signatures coming soon. |
|
|
|
Could someone with a Raspberry Pi try it out and let me know if it works fine? That would be great.
whiskers75@WhiskPi ~$ python NoBrainr.py
13PVpJfC1umtPybToQdPbAx81ayqLgzxbU == gnaws smoke amount styx stem spam sews
Great news! Thanks for trying it |
|
|
|
|
This doesn't look good... Another thought: do you have Time Machine (or similar) functionality enabled in your OS? If so, you could try to restore a previous version of the wallet file. Otherwise you may want to contact ThomasV (lead developer of Electrum) and ask for help.
|
|
|
|
Version of Electrum?
Also FYI, Armory, MultiBit and Electrum each use their own wallet format and can't import wallets from each other, unfortunately (only addresses).
At the time of the corruption it was 1.9, since then I have updated to 1.9.2 to see if it would resolve any issues. OK, try this. I can't guarantee it will work, but it's definitely worth trying. 1/ start electrum and create a *new*, empty temporary wallet. 2/ encrypt it with the *same* password as your corrupted wallet. 3/ exit electrum 4/ open the corrupted wallet file in notepad. 5/ find and copy the encrypted 'seed' value to the clipboard. it should be a long text string ending with equal signs - something like: 'MVE+ARAQzc73hvafKTo1ZHT0CAajPw==' 6/ open the new wallet file in notepad. 7/ replace the 'seed' value there with the contents of the clipboard. 8/ save, exit notepad, and start electrum 9/ click the seed icon to (hopefully) retrieve your seed 10/ you're almost done. do NOT use this new wallet. delete it and create a new wallet by restoring your seed. 11/ let it synchronize, cross your fingers and you should have your coins again. |
|
|
|
|
Version of Electrum?
Also FYI, Armory, MultiBit and Electrum each use their own wallet format and can't import wallets from each other, unfortunately (only addresses).
|
|
|
|
|
Do you know the password? If so, there's something you can try. I will post instructions later today.
|
|
|
|
|
If the dat file is not encrypted, open it in notepad and look for "seed".
You should find a 32-digit hexadecimal string. Copy it, rename your dat file,
start electrum, and at the "new wallet" screen, choose to restore from seed.
When prompted, paste your 32-digit code to recover your wallet.
|
|
|
|
Make sure to import/spend the entire amount of bitcoins per paper wallet. Every sheet of paper should have the exact amount of coins you put there so you can cross compare.
You can generate paper wallets with a script on your personal computer so you can assure nobody has seen your private.
You can boot ubuntu from a usb stick and create paper address with an offline address generation javascript code available if you search on google.
You may also want to check out NoBrainr (see signature), made just for this |
|
|
|
Just a little example to help measure and understand the safety of a 7-word NoBrainr brainwallet more intuitively: consider a random 15-character password with upper case, lower case, and digits. For instance: uhTmb41M5k9ijWrthis is 89-bit strong (but hard to remember): log((26+26+10)^15,2) == 89.31294465580312 (2^89 = 7.82 x 10^26) Test it at: https://www.grc.com/haystack.htmTime required by Massively Cracking Array Scenario:
(Assuming one hundred trillion guesses per second)
-> 2.48 thousand centuries
At 90 bits, any 7-word NoBrainr brainwallet is at least as safe: log(7776^7,2) == 90.47368752524046 1LGHodpRUXaE4q3Z3LiHSU8TT7czxsxccc == salt dorm reduce fab! truck kind pi!
|
|
|
|
|
No other packages are needed. Sorry, can't give a longer answer now, I'm running late...
|
|
|
|
A 90-bit passphrase, *IF* randomly generated (as this script is doing), has
NEVER been cracked and it will most likely not be in our lifetimes.
Bitcoin has now done ~2^74 hash operations. I'm reasonably confident that it will do 2^90 of them in my lifetime, I am not confident that it will be the only 2^90 search. Yes bitcoin has done 2^74 operations but at what total cost? In the tens or hundreds of millions USD, if I'm not mistaken. Also the workfactor to break one of your 90 bit keys is less than 2^90 the moment two of your keys have been used... If your scheme were widely used, it would be much easier to find one at random. It may also turn out that your RNG is less uniform than believed and after careful analysis doesn't require a 2^90 search to match even a single key.
The script is feeding straight from /dev/urandom (SystemRandom in python). That's easy to verify from the 25-line source code. It will also support another randomness method that totally bypasses the OS provided RNG, which should cater to the most paranoid amongst us... In general symmetric cryptography applications 128 bits has arisen as a general standard. Is 128 meaningfully better than 90? Is it meaningfully better than 120? Meaningfully better than 65? Part of the purpose of having a standard size is so that you don't have to constantly engage in a complicated tradeoff discussion: you just demand that everything is 128 bits.
The objective of this tool is to provide keys that can be remembered by a normal human being and can't be cracked easily. 2^90 achieves this, which is also the view that many password strength experts hold (eg: agilebits, diceware, Schneier, us gov internal recommendations, etc) Also as stated earlier, just changing one digit in the code makes it generate much stronger passphrases, if required for whatever reason or belief. Your scheme also only generates a single address, so users are stuck reusing it, compromising their privacy.
This is a well-known brainwallet limitation that affects all commonly used brainwallet generators (bitaddress, brainwallet.org, etc). This is why it is recommended to use a brainwallet address only once (just like any other bitcoin address, really). At least NoBrainr provides random generation for brainwallets, which the other approaches don't, and provides strong 90-bit + keys, compared to the 30 to 40 bit (song lyrics, poems, etc) that many people use to generate their brainwallets on those sites. The slightly confusing thing with the "brainwallet" moniker is that it is actually just one address, so not a wallet in the regular bitcoin-client sense. This is part of the reasons that only advanced users should even consider using brainwallets, and only after researching them properly.
Is 128 bits more to memorize than 90? Yes. But relying on memorizing keys which can never be recovered via any other means is already skating on thin ice. People are used to it being possible to recover access if you forget— though sometimes with great effort. Crypto is different. Memory is just reliable enough for its unreliability to be surprising, especially since you don't remember all that you've forgotten by definition.
Of course, once you're up to that size you could just use the scheme electrum uses (or the one that it will use). Of course, the implementation isn't 1024 bytes— but neither is yours: The dictionary is an utterly essential part of the implementation.
Of course the dictionary is essential, but the point is that 1024 bytes / 25 lines of code makes NoBrainr orders of magnitude easier to audit and review, compared to any other alternative. This can make all the difference for non-developers or anyone who doesn't have days to waste just to make sure nothing malicious is going on in the source code. |
|
|
|
At the risk of sounding like a complete dumbass: couldn't a hacker create a rainbow database with all of these brainwallet combinations, and see which ones are filled with dough?
Is it inconceivable that the hacker will be successful in finding BTC in some of his computer generated brainwallet phrases?
Hi, I'm responding from my phone, so sorry for the short answer, but basically the passphrases produced by NoBrainr are each guaranteed to be above 90-bit strong, which makes any brute-force attack (including rainbow tables) prohibitively expensive - think billions of dollars and centuries to crack one passphrase, even for massively distributed supercomputers or botnets. In my view, higher bit strength in this case is overkill, but the paranoid can further increase the bit strength by changing one line in the code, or even use physical entropy as input (more on that soon!) Thanks for the speedy reply, appreciate it. I have been getting hammered for favoring brainwallets lately. I have proposed inventing my own language and coming up with a passphrase that way, which has been deemed as a terrible idea. So please forgive me for displaying shock at your seven plain-English word phrases. The general feedback I seem to get from the naysayers is that it is folly to have the computer generate a passphrase for you, and use that generated passphrase for a brainwallet. The only appropriate solution that has been offered is to play with some dice, and only to generate the the private keys at that. If your brainwallets are indeed actually safe, I would rather go with brainwallets than roll dice for just private keys each time. If most NoBrainr passphrases look so deceptively simple to you, it means we are achieving our objective, which is to provide brainwallets and paper wallets that are both easy to remember, and highly resistant to any type of automated guessing/cracking. It is scary to see how misunderstood the concept of passphrase entropy is, even within the otherwise tech-savvy bitcoin community. We do recommend users to proceed with caution when using brainwallets. In other words, you really need to know what you are doing. However, one thing that you will NOT see happen is a cold NoBrainr generated brainwallet being snatched by a random hacker. We will even consider putting up a bounty to anyone who can show a real-life example of a vulnerability in NoBrainr leading to theft of BTC. |
|
|
|
At the risk of sounding like a complete dumbass: couldn't a hacker create a rainbow database with all of these brainwallet combinations, and see which ones are filled with dough?
Is it inconceivable that the hacker will be successful in finding BTC in some of his computer generated brainwallet phrases?
Hi, I'm responding from my phone, so sorry for the short answer, but basically the passphrases produced by NoBrainr are each guaranteed to be above 90-bit strong, which makes any brute-force attack (including rainbow tables) prohibitively expensive - think billions of dollars and centuries to crack one passphrase, even for massively distributed supercomputers or botnets. In my view, higher bit strength in this case is overkill, but the paranoid can further increase the bit strength by changing one line in the code, or even use physical entropy as input (more on that soon!) |
|
|
|
Thanks - I think I'll try to use bitaddress.org with the "brainwallet" function (but with a passphrase generated randomly from /dev/random).
You can also use the "Paper wallet" tab and BIP38-encrypt the private key. Ah thanks, I didn't know that. But I just want a single private key & address pair, so I probably don't need that. I'll try it out soon! Regarding NoBrainr: It seems that it needs some additional Python libraries (ecdsa at least) - which I would need to also install on the TAILS system once booted up. Thanks for looking at NoBrainr! I just want to confirm that it requires the ecdsa library indeed, which is a tiny 90Kb package from the pypi central python repository (and used by countless other bitcoin apps, including Electrum.) Keep in mind that a great feature of NoBrainr is that it is only about 25 lines of code, making it orders of magnitude simpler than alternatives, while still producing cryptographically strong keys. Also, it will soon accept real physical entropy as input, bypassing any NSA-backdoored RNG concerns. |
|
|
|
OK, just something that may interest the most paranoid among us: the next version will also support a PHYSICAL entropy source (guess which... here's a hint: 6**5 ), and will still be under 1024 bytes! |
|
|
|
|
Or have a look at NoBrainr, it's barebones (20 lines of code!) and robust.
|
|
|
|
|
Show Posts
