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

flatfly

legendary

Activity: 1106

Merit: 1016

090930

I'm also working on a version that produces English sentence-like output. Some find that easier to remember (even if the sentences sound kinda crazy and are obviously not 100% correct).

Examples:

Code:

Fri 02/28/2014 7:25:36.32> python gibb.py
Some banner leak basked my zag, and a monk gadgeted your about.

Fri 02/28/2014 7:29:58.46> python gibb.py
My trio unleashed many sects, and all feign stalled my clause.

Fri 02/28/2014 7:29:59.48> python gibb.py
Their scream edgared any cite, and that slid wheated the prayer woe from birth.

Fri 02/28/2014 7:30:00.43> python gibb.py
The weigh chains a bleak, and the irked bulky yayed your ipod!

Fri 02/28/2014 7:30:01.26> python gibb.py
Any coming sad missed the prince, and any poodle snowed those ms.

Fri 02/28/2014 7:30:02.09> python gibb.py
A miner gene is ending the clad, and the sliver often agonyed the perky.

Fri 02/28/2014 7:30:02.75> python gibb.py
That geese ardented your swam, and the ounce santaed my city.

Fri 02/28/2014 7:30:03.46> python gibb.py
Any olson vouched this raged noah, and this summer conrad raided the virgin.

I still have to clean up some ~~minor~~ stuff before posting the code, which is based on a recent coding contest entry.

flatfly

legendary

Activity: 1106

Merit: 1016

090930

Quote from: flatfly on December 05, 2013, 11:58:36 AM

Quote from: ?? on ??

Quote from: flatfly on November 21, 2013, 03:24:20 AM

AFAIK, it could only make a tangible difference in one specific scenario: if you were to run the command immediately (in the first few seconds) after a cold boot of a livecd distro.

If you do that with /dev/urandom, you'll have created an insecure key.

If you do it with /dev/random, you block for a short while.

What's the advantage to using /dev/urandom? Is it because some platforms don't support /dev/random?

(Depending on how you're implementing things there are probably other potential problems if you're creating lots of keys.)

/dev/urandom and /dev/random each have their pros and cons, which you can find with a little bit of googling.
Bottom line is, everyone agrees on /dev/urandom being just fine for cryptography.

Here's a first link to get you started:
http://security.stackexchange.com/questions/40633/java-securerandom-doesnt-block-how

Another good piece, strongly favoring urandom over random (in general):
http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/

Of course, one has to be aware of the caveats of urandom when relying on it.
But then again, NoBrainr is intended for advanced users anyway.

flatfly

legendary

Activity: 1106

Merit: 1016

090930

I have uploaded a new revision of DICT, with 94 additional words replaced with less obscure alternatives.

flatfly

legendary

Activity: 1106

Merit: 1016

090930

Quote from: Evil-Knievel on January 26, 2014, 05:58:29 AM

Is there an estimate how many people used NoBrainr so far and whether they have used it for large high-roller cold wallets?
If so, when did NoBrainr come out?

Sorry, I don't keep track of that.

nimda

hero member

Activity: 784

Merit: 1000

0xFB0D8D1534241423

Quote from: Evil-Knievel on January 26, 2014, 05:58:29 AM

Is there an estimate how many people used NoBrainr so far and whether they have used it for large high-roller cold wallets?
If so, when did NoBrainr come out?

flatfly might be able to give you a downloads total, but no cold wallet generated by NoBrainr can be identified as such.

Evil-Knievel

legendary

Activity: 1260

Merit: 1168

This message was too old and has been purged

flatfly

legendary

Activity: 1106

Merit: 1016

090930

Quote from: nimda on December 14, 2013, 01:49:41 PM

Quote from: flatfly on December 01, 2013, 09:50:12 AM

Edit: Hmm not sure how to avoid that emoticon... read: range ( 8 )

Under the post box:

"Additional Options..."
"Don't use smileys."

Good to know - thanks!

nimda

hero member

Activity: 784

Merit: 1000

0xFB0D8D1534241423

Quote from: flatfly on December 01, 2013, 09:50:12 AM

Edit: Hmm not sure how to avoid that emoticon... read: range ( 8 )

Under the post box:

"Additional Options..."
"Don't use smileys."

flatfly

legendary

Activity: 1106

Merit: 1016

090930

Quote from: ?? on ??

Quote from: flatfly on November 21, 2013, 03:24:20 AM

AFAIK, it could only make a tangible difference in one specific scenario: if you were to run the command immediately (in the first few seconds) after a cold boot of a livecd distro.

If you do that with /dev/urandom, you'll have created an insecure key.

If you do it with /dev/random, you block for a short while.

What's the advantage to using /dev/urandom? Is it because some platforms don't support /dev/random?

(Depending on how you're implementing things there are probably other potential problems if you're creating lots of keys.)

/dev/urandom and /dev/random each have their pros and cons, which you can find with a little bit of googling.
Bottom line is, everyone agrees on /dev/urandom being just fine for cryptography.

Here's a first link to get you started:
http://security.stackexchange.com/questions/40633/java-securerandom-doesnt-block-how

flatfly

legendary

Activity: 1106

Merit: 1016

090930

Quote from: thezerg on November 30, 2013, 11:35:54 PM

You may know this, but, "salting" a password is the technique of putting a completely obvious but mostly unique phrase into the password so that an attacker must specifically attack each individual rather than allowing him to attack everyone at the same time by creating a brute-force dictionary for all combinations. At the same time this additional data is chosen to be very easy to remember. For example, the passphrase "thezerg hello world" is much harder than just "hello world". I think NoBrainr could benefit from salting.

def main(salt=None):
if salt: salt = salt + " "
else: salt = ""
f = open('DICT')
if len(sys.argv)>1:
wd = dict(x.split() for x in f)
pp = salt + ' '.join([wd

for x in sys.argv[1:16]])

else:
wd = [x.strip('\n') for x in f]
pp = salt + ' '.join([wd[random.SystemRandom().randrange(0,len(wd))][6:] for _ in range(7)])

pr = S(pp).hexdigest()
print addr(int(pr,16)),'==',pp

Thanks for your contribution. In general, I'm all for salting, but it mostly helps protect _weaker_ (human-chosen) passwords against "en masse" cracking. As the passphrases we are generating here are all
equally strong (90+ bits, or much more if you are comfortable with remembering longer passphrases),
I think that salting wouldn't bring that much additional benefit _in this context_.

Also you could simply generate passphrases with one more word - just by changing range(7) into range( Cool

-
and think of the first word as the salt... You can even allow yourself to cherrypick it (generate passphrase upon passphrase until you get a first word that you like), since it is your "salt."
Most words in the NoBrainr wordlist can be described as "completely obvious" anyway.
And I'm constantly improving the wordlist (by replacing the less common and offensive words.)

Edit: Hmm not sure how to avoid that emoticon... read: range ( 8 )

thezerg

legendary

Activity: 1246

Merit: 1010

You may know this, but, "salting" a password is the technique of putting a completely obvious but mostly unique phrase into the password so that an attacker must specifically attack each individual rather than allowing him to attack everyone at the same time by creating a brute-force dictionary for all combinations. At the same time this additional data is chosen to be very easy to remember. For example, the passphrase "thezerg hello world" is much harder than just "hello world". I think NoBrainr could benefit from salting.

def main(salt=None):
if salt: salt = salt + " "
else: salt = ""
f = open('DICT')
if len(sys.argv)>1:
wd = dict(x.split() for x in f)
pp = salt + ' '.join([wd

for x in sys.argv[1:16]])

else:
wd = [x.strip('\n') for x in f]
pp = salt + ' '.join([wd[random.SystemRandom().randrange(0,len(wd))][6:] for _ in range(7)])

pr = S(pp).hexdigest()
print addr(int(pr,16)),'==',pp

moderate

member

Activity: 98

Merit: 10

nearly dead

Quote from: dhingydog on November 30, 2013, 06:56:34 PM

Quote from: moderate on November 30, 2013, 05:49:40 PM

Quote from: dhingydog on November 30, 2013, 05:41:51 PM

A user not familiar with the math of password strength, I believe, is highly likely to generate a set of passwords and then choose the most pleasing one. The result: Possibly a significant loss of entropy.

That makes no sense whatsoever. Except if the generator is broken.

Well, picking one favourite password out of 10 random ones adds human emotion, which isn't exactly random, is it?

You're still failing to see why it makes no sense, so I will try to be clearer this time. IF the generator was generating passwords where one of them was weaker than the others, it doesn't matter if you picked the first one, the second one, the 1231212312313th one, because you don't know* if the first one was weak, or the second one, etc, so they are all equally weak. Either the generator always generates good passwords, or it doesn't and is a broken generator. Please don't reply to this just to reply, think about it.

dhingydog

newbie

Activity: 19

Merit: 0

Quote from: moderate on November 30, 2013, 05:49:40 PM

Quote from: dhingydog on November 30, 2013, 05:41:51 PM

A user not familiar with the math of password strength, I believe, is highly likely to generate a set of passwords and then choose the most pleasing one. The result: Possibly a significant loss of entropy.

That makes no sense whatsoever. Except if the generator is broken.

Well, picking one favourite password out of 10 random ones adds human emotion, which isn't exactly random, is it?

Say, something like: "Hey, that one has my girlfriend's name in it, I'll choose that!".

moderate

member

Activity: 98

Merit: 10

nearly dead

Quote from: dhingydog on November 30, 2013, 05:41:51 PM

A user not familiar with the math of password strength, I believe, is highly likely to generate a set of passwords and then choose the most pleasing one. The result: Possibly a significant loss of entropy.

That makes no sense whatsoever. Except if the generator is broken.

dhingydog

newbie

Activity: 19

Merit: 0

One thing the generator doesn't (and probably can't?) guarantee is that the user actually took the password the generator first gave out.

A user not familiar with the math of password strength, I believe, is highly likely to generate a set of passwords and then choose the most pleasing one. The result: Possibly a significant loss of entropy.

Have you considered adding an output of instructions and warnings about how and how not to use the generator?

frito_mosquito

newbie

Activity: 8

Merit: 0

Hi All,

Perhaps this would be worth starting a new topic, but I thought would dip my toes in here first, as I think the NoBrainr software touches on several of my requirements.

I too seek a slick, light, wallet (a stand alone operating system that can be run on a LARGE percentage of machines, regardless of architecture), that supports entropy given from the user. I have one put together, but I don't yet trust my programming with anything of value (it is still being tested).

And furthermore, I want my light wallet to broadcast transactions! Electrum seems like the answer, but as I tested it today I was not able to log into their servers from the client.

Obviously, a computer with a freshly installed operating system would not be able to construct a transaction. The client must know something about the blockchain to construct transactions, but what exactly? What is the minimum amount of information required to construct a transaction?

tl;dr:
Are you currently aware of any wallets that meet the following criteria:

Generates private keys offline.
Does not download the entire blockchain
Can construct and broadcast transactions to full bitcoin nodes directly by getting information required to construct transactions from the bitcoin nodes themselves (IE, does not have to interface with a third party server like Electrum)

Clearly I need to learn more about transactions, and the current debate about fees, mining, and block-size has my head spinning.

Regards,
Frito_Mosquito

Dabs

legendary

Activity: 3416

Merit: 1912

The Concierge of Crypto

Quote from: ?? on ??

Now that I think about it, there's probably a tiny advantage to doing it that way in that 1000 pictures are less likely to be recoverable if your secure deletion doesn't work that well. At least if you fill up the card, dump it to your air gapped computer, delete the card, and then fill the card up again.

That's the poor man's secure delete or wipe method. Fill up the memory card again.

Here are the steps to do this securely:

1. Turn off wifi or bluetooth on your camera.
2. Take 1000 pictures (or until card is full.)
3. Download those pictures to an air-gapped offline computer using sneakernet methods (do not use wireless)
4. Format the card in your camera again.
5. Take pictures until card is full (or take video if your camera can do it, so it fills up faster.)

If you use a secure delete or secure overwrite/wipe utility, you might ruin your card (which is just as well.)

flatfly

legendary

Activity: 1106

Merit: 1016

090930

Quote from: moderate on November 20, 2013, 04:50:28 PM

Quote from: flatfly on November 20, 2013, 04:04:12 PM

Quote from: ?? on ??

Quote from: flatfly on November 20, 2013, 03:18:02 PM

Quote from: Dabs on November 19, 2013, 09:48:09 PM

Suggestions:

1. Have it print or save the private key in WIF format as well, as an option.
2. Make it generate compressed keys (private keys begin with letter L or letter K instead of number 5.)

If size is a problem (to fit in 30 lines), make it a separate app?

Great suggestions. We'll look into that - or anyone can contribute a patch, of course.

Also you may want to have a look at Urandom2Wif - it has a small WIF format function (courtesy of JeromeS), which could very easily be added to NoBrainr:
https://bitcointalksearch.org/topic/urandom2wif-338219

Shouldn't this sort of application be using /dev/random rather than /dev/urandom?

It's a good question, and one which I've actually researched quite a bit. I won't elaborate on this too much right now, but the short answer is no - it doesn't make a difference in practice, at least for this tool.

You might not want to elaborate too much, but at least elaborate a little then.

I will start it. urandom may reuse the entropy pool or whatever else a specific OS might want to do to ensure a call to that never blocks. Why do you say it doesn't make a difference when compared to /dev/random which doesn't reuse the pool and is thus considered safer for crypto purposes ?

AFAIK, it could only make a tangible difference in one specific scenario: if you were to run the command immediately (in the first few seconds) after a cold boot of a livecd distro.

This has been discussed multiple times on this forum, and even the most secure bitcoin apps/wallets choose to use urandom.

If you're a little paranoid, just mash your keyboard for a couple seconds before generating an address.

And if you're extremely paranoid, use the physical dice mode of NoBrainr.

EDIT: This might be an interesting thread to follow:
https://bitcointalksearch.org/topic/electrum-cracker-341476

Dabs

legendary

Activity: 3416

Merit: 1912

The Concierge of Crypto

Quote from: ?? on ??

I was kind of kidding about the dice, actually. I think I could just take a picture of my closet, tell everyone that I'm taking a picture of my closet, invite people to come visit my house and look at my closet, let anyone who wanted to borrow my camera do so, and yet trying to recreate a picture with the exact same SHA-256 still wouldn't be a viable attack vector.

Once, I'm going to go around town or around the block or something, and start taking random pictures of things I don't really like. Highest ISO. Highest shutter speed. Highest resolution. RAW if possible, or largest JPEG. I'll end up with 1000 pictures that can be deleted after I've gotten the SHA-256 of each one.

I think that's just for the fun of it. It's overkill. NoBrainr and almost any other offline generating tool will work fine.

I use one called PWGen.
http://pwgen-win.sourceforge.net/

It's also fun to try memorizing an actual randomly generated 32+ character password. Thousands of people do it with Pi to 50~100 places. A 3 year old girl memorized 31 digits of Pi.

Dabs

legendary

Activity: 3416

Merit: 1912

The Concierge of Crypto

Quote from: moderate on November 20, 2013, 08:37:47 PM

Quote from: Dabs on November 20, 2013, 08:17:17 PM

When you turn off the offline computer immediately after generating the cold wallet address, then how much does the reuse of entropy pool matter?

That has no meaning whatsoever.

Okay, I'm confused. What has no meaning? What I said? Or, the reuse of entropy pool has no meaning?

Quote from: ?? on ??

Quote from: Dabs on November 20, 2013, 08:17:17 PM

I'm guessing, this should be run offline. When you turn off the offline computer immediately after generating the cold wallet address, then how much does the reuse of entropy pool matter?

Let it run a few hundred times, pick one or two in the middle and use those.

What if you're running from a LiveCD?

Roll a pair of dice, take a picture of the dice, run the jpeg through SHA-256, use that as your key, and then securely delete the picture

.

I've also suggested that, but use 100 actual dice per private key you want to generate, the maximum resolution (or RAW format), and the highest ISO setting.

Topic: NoBrainr - a secure and transparent cold address generator in 1024 bytes (Read 12573 times)