NoBrainr - a secure and transparent cold address generator in 1024 bytes

[riplin]

Code:

random.SystemRandom().randrange(0,len(words))

Given all the recent discussions about compromised randomisers, it would be wise to do some form of whitening on the output. Feeding it through HMACSHA256 with a random key and input of, say another 256 bits of data is pretty strong.

[1714951335]

1714951335

[KenKaniff]

.

[jago25_98]

Code:

[user@localhost bin]$ python NoBrainr.py 
Traceback (most recent call last):
  File "NoBrainr.py", line 22, in <module>
    words = [x.strip('\n') for x in open('DICT')]
IOError: [Errno 2] No such file or directory: 'DICT'
[user@localhost bin]$ mv DICT.txt DICT
[user@localhost bin]$ python NoBrainr.py 
Traceback (most recent call last):
  File "NoBrainr.py", line 25, in <module>
    print addr(int(pr,16)), '=', pp
  File "NoBrainr.py", line 5, in addr
    pko=ecdsa.SigningKey.from_secret_exponent(pk,ecdsa.curves.SECP256k1)
AttributeError: 'module' object has no attribute 'SECP256k1'

[knowitnothing]

Code:

[user@localhost bin]$ python NoBrainr.py 
Traceback (most recent call last):
  File "NoBrainr.py", line 22, in <module>
    words = [x.strip('\n') for x in open('DICT')]
IOError: [Errno 2] No such file or directory: 'DICT'
[user@localhost bin]$ mv DICT.txt DICT
[user@localhost bin]$ python NoBrainr.py 
Traceback (most recent call last):
  File "NoBrainr.py", line 25, in <module>
    print addr(int(pr,16)), '=', pp
  File "NoBrainr.py", line 5, in addr
    pko=ecdsa.SigningKey.from_secret_exponent(pk,ecdsa.curves.SECP256k1)
AttributeError: 'module' object has no attribute 'SECP256k1'

Your python-ecdsa is too old (more than 1 year old), check out https://github.com/warner/python-ecdsa for the latest version.

[knowitnothing]

An new release (1.043) is now available.
The code is now even shorter (999 bytes!), and dozens of entries in the wordlist have been updated with more intuitive words.

Reminder: Linux and Mac versions require the latest release of the ecdsa library:  sudo pip install ecdsa

If you are interested in keeping it even shorter, here is a cooler version at 888 bytes:

Code:

import random,ecdsa,binascii,hashlib

unhexlify=binascii.unhexlify
sha256=lambda x:hashlib.sha256(x).hexdigest()
def addr(pk):
 pko=ecdsa.SigningKey.from_secret_exponent(pk,ecdsa.curves.SECP256k1)
 puk=binascii.hexlify(pko.get_verifying_key().to_string())
 puk2=sha256(unhexlify('04'+puk))
 puk3=hashlib.new('ripemd160',unhexlify(puk2)).hexdigest()
 puk4=sha256(unhexlify('00'+puk3))
 puk5=sha256(unhexlify(puk4))
 puk6=puk3+puk5[:8]
 pubnum=int(puk6,16)

 pubnumlist=[];address=''
 while pubnum!=0:pubnumlist.append(pubnum%58);pubnum/=58
 for l in ['123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'[x] for x in pubnumlist]:
  address = l+address
 if len(address)<32:address = '1'+address
 return '1'+address

words = [x.strip('\n') for x in open('DICT')]
pp = ' '.join(map(lambda x:x[6:], random.SystemRandom().sample(words, 7)))
pr = sha256(pp)
print addr(int(pr,16)),'=',pp

It is possible to make it even shorter (ignoring renaming stuff to single letters or other meaningless names) by using from binascii import * and building the address in a single line.

[TheButterZone]

OSX 10.6.8

$ sudo pip install ecdsa
Password:
sudo: pip: command not found
$

[gmaxwell]

I'm unhappy with the subject line describing this as "hack proof", it's strictly weaker than other similar systems. (E.g. what electrum does)

[flatfly]

I'm unhappy with the subject line describing this as "hack proof", it's strictly weaker than other similar systems. (E.g. what electrum does)

Well for all practical purposes 90-bit real entropy does effectively prevent bruteforcing.  IMHO, it is unlikely to be cracked in our lifetimes. If someone would like to do the math once again, they are welcome.

Sure Electrum uses 128-bit seeds, but at the expense of having to remember 12 words (versus only 7 here) while providing little extra benefit *in practice* (from a security point of view)  

Also, if needed, one could just change 'range(7)' into 'range(10)' in the code and instantly higher bit strength than Electrum (130 bits.)

Still, I may change the title to 'bruteforce resistant' or 'lifetime secure' if you prefer.

[flatfly]

OSX 10.6.8

$ sudo pip install ecdsa
Password:
sudo: pip: command not found
$

You probably need homebrew: http://brew.sh
Then, at a prompt: "brew install pip"

[flatfly]

Release 1.047 is ready!

Release notes:
 - greatly improved word list
 - generates CONSTANT strength passphrases, regardless of the character length (actually, this is not new - just a reminder!)
 - a secondary script has been added, which can be used to perform basic integrity checks on the word list
 - path issues have been fixed in the windows version

[flatfly]

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!

[Five Points]

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?

[flatfly]

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

[Five Points]

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.

[flatfly]

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.

[scribe]

Great stuff, looks perfect for a small project I'm thinking about, so will be taking a look soon.  Any tips for running it on something that's never been connected to the net to avoid risks?  Eg a useful live Linux distro plus way to get this script across to the machine in question?

[Five Points]

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.

That's why I'm surprised you are so confident about it. Most people have dreaded the brainwallet, so to see someone champion it with only seven plain English words is bewildering.

People are losing their money over horrible brainwallets, yet all they needed were seven easy to remember English words, and they are totally unhackable. Unbelievable...

[dserrano5]

That's why I'm surprised you are so confident about it. Most people have dreaded the brainwallet, so to see someone champion it with only seven plain English words is bewildering.

The problem isn't the brainwallet concept in and of itself, but people's poor choices when picking up a passphrase. NoBrainr takes care of that.

[Five Points]

That's why I'm surprised you are so confident about it. Most people have dreaded the brainwallet, so to see someone champion it with only seven plain English words is bewildering.

The problem isn't the brainwallet concept in and of itself, but people's poor choices when picking up a passphrase. NoBrainr takes care of that.

I was going to invent my own language, I thought that would be more than sufficient for me. But these initial worries from detractors had me stopped in my tracks...

[gmaxwell]

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.

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.

Your scheme also only generates a single address, so users are stuck reusing it, compromising their privacy.

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.

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.