Topic: Armory - Discussion Thread - page 95. (Read 521855 times)

Okay guys, I am sure this whole random source discussion is totally exaggerated.
Quit it.
Right now.

You see, I am already thinking about combining that rasbpi and that old radiation source from a smokedetector for a secure, true random, convenient randomness-server.
Which may or may not collect additional randomness sources and XOR them all together.

Any, wtf, they found a hardware rng in the rasbpi:
http://hsmmpi.wordpress.com/2013/09/05/enabling-the-hardware-random-number-generator/

..still want my very own source, though..

Alan, whatdaya think?

Ente

It's also a very innocuous way to smuggle keys, using a pre-'shuffled' deck. See also: solitaire encryption algorithm.

Cool, I like it.  225 bits of entropy if your shuffle is perfect.  And a lot less noisy, too!

Shuffle a single deck of cards very well. Write out the ordering using whatever scheme works for you, and hash256(). Repeat if you are unsure about the quality of your shuffle. (1 perfectly shuffled deck of cards is approximately 225 bits of entropy.)

I actually made my own device, using my recent obsession with 3D printing:

http://www.thingiverse.com/thing:167019

I made this so you can roll four dice at a time without any ambiguity about ordering.  Though, my experience has shown that if you hold it only from one side, the die closest to you doesn't get shaken enough for full entropy.  I'm still trying to figure out how I would make this more robust to human error (though, the other three dice get a lot of rolling entropy and thus if you do 2x-3x the number of rolls you'd need if they were all rolled perfectly, you'll still accumulate plenty).

http://www.geekchichq.com/entropy-engine.html

http://www.geekchichq.com/dice-tower.html

Personally, if you want to do this right without worrying too much, I would simply get a bunch of dice and collect 100-150 D6 rolls (that's 256-384 bits of entropy, if it was all perfect).  Make the process of ordering the dice rolls as deterministic as possible, to limit the amount of "human influence" on the results.  Just type them into a a python shell string hash256() the result.  Use that as your private key/seed. 

You only need 128 bits of real entropy for a secure private key/seed.  As long as there's no gross human influence the results (such as insufficient shaking/rolling, or selectively ordering the dice rolls), then you should easily get enough entropy out of 100-150 rolls.   And it should take you no more than 5 minutes.

You could do the FIPS thing, but that requires converting the result into an integer and applying the modulus, both of which may be beyond some folks in concept, or available libraries.  Doing a sha256²() or HMAC() is totally sufficient for converting arbitrary data to a private key, as long as that data has sufficient entropy.

There are random streams out there that come from analog physical processes, like atmospheric noise, quantum noise etc ... (but then of course you are trusting the stream providers).

http://www.random.org/bytes/

http://150.203.48.55/index.php

https://qrng.anu.edu.au/RainHex.php

HexRain as a number stream from vacuum fluctuations ...

How much less than full entropy is "good enough"?

If used properly, even a shitty key can be good enough, just as long as it isn't too shitty.

But, key abuse is rampant in bitcoin.  You also can't constrain the future use of the key when you make it.  Since you can't be sure that you won't, some day in the far future, abuse your key, you should endeavor to make your keys as securely as possible.

The only advice I'm ever willing to give people is to pack as much entropy into their keys as they possibly can.  If they want to cut corners, that's on them.

The modulus trick is great.  I don't know how I missed it in my travels through the FIPS manuals.  It seems like a very effective way to blend extra entropy throughout the entire key.  I'm going to steal it for my offline paper wallet generator.  Since I haven't yet made a geiger tube collector, I'm always skeptical of my entropy sources.

The real issue being brought up by kjj is simply that you may not be getting full entropy out of the rolling if there's any subjectivity involved.  However, even if you aren't rolling dice properly, you are still getting entropy, just not full entropy.  Consider that you roll a die 32 times, and you don't properly re-roll it and you get the exact same number as the last roll half the tie.  Well, then you got 16 dice-rolls-worth of entropy instead of 32.  Not ideal, but you're still producing nice analog entropy -- just not as much as you thought.

For this reason, if you use something like dice rolls, coin flips, etc.  I recommend you do maybe 2-3x the number of rolls/flips than you are really looking for.  Especially because this operation is done so infrequently, a little patience up front is worth it to have the extra confidence. 

Hashing the result is sufficient, though the FIPS method sounds good too, where F is the order of the secp256k1 group, which is 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 (bigendian)

If I remember correctly, the FIPS recommended way of building an EC private key was to take at least 1.5 times more entropy than the key bit length and modulo it by F. I would personally recommend that way too, as F (or whatever that parameter was called) is less than 2^256 for secp256k1.

But calculating the corresponding bitcoin address by hand might be error prone, and it would be really nasty transferring funds to a wrongly calculated address.

But then, just import the private key in an armory wallet, check that it gives a bitcoin address, and then use it.

If you have the correct number of bits, there is no such thing as an "invalid key".

There are fewer places to screw up, but still not none.  Again, use a cup, try tossing it the same way each time, don't look at the coin before/during tossing, use a flat tray with a marked border, write down exactly what comes up even if you don't think it looks "random enough", etc.

That makes me wonder, isn't it "easier" to just toss a coin 256 times? Sure, you may get bored in the process but you get rid of all those considerations about 6s vs 9s, or which face is up. Or use 4 coins of different value and read them always in the same order, for a total of 256/4 tosses.

Uh, actually it is surprisingly easy to fuck up dice rolling for entropy.  Any attempt to extract entropy from gross physical processes that requires human work is prone to failure.  Just ask everyone that tried it during World War II.

Ideally, you should build a machine that shakes the dice in a cup and tips the cup into a flat, level tray.  At the very least, use a cup, try to tip the cup the same way each time, and for the love of god, don't look in the cup while shaking or tossing.  The tray should have a line painted in it about 1.5 die radiuses away from the wall and you should ignore any rolls where any of the dice touch or cross that line.  Also reject any rolls where the dice are touching.  Since dice touching can be somewhat subjective, it is also a good idea to reject any rolls where the dice end up within some objective threshold of each other, 1.5 radiuses perhaps.  Build a gauge block of the appropriate width and taller than the dice and try to slip it between the dice if they are even remotely close.*

Next, all of your dice need to be different and distinct colors, and all faces must be instantly distinguishable (that means you need dots or lines on both 6 and 9, not just one).  You must always assemble the rolls into your number in the same way.  Print a data collection sheet with boxes, and color code the boxes to match the dice so that you don't mess up the ordering.**

And finally, never, ever, ever reject throws for subjective reasons.  You must be extremely vigilant about this.  Your natural tendency will be to reject throws that don't look random enough, or just don't look right in some obscure way.  You must fight these thoughts and write down the data collected, exactly as it comes up, regardless of your personal feelings.

You'll note that most of my advice is in the area of removing your own judgement from the system.  Your brain is a shitty discriminator of entropy, and if you let it interfere with the process, you will get shitty entropy out.  During World War II (and the cold war, for that matter), office staff on all sides of the war were trained to generate encryption codes and pads by using physical systems like dice.  They usually failed (and their codes were cracked, and people died) because they would have unhelpful thoughts like "that's too many 7s to be really random.  I'm going to change a few".  And that was generally after being trained specifically not to do that, and that lives depended on the quality of their work.  Odds are very good that you will do at least as poorly as they did.

* The common theme here is to reject any rolls where the dice might be leaning on the wall or on other dice, which is to say when they might not be completely flat, which is to say when human judgment might possibly come into deciding which face is up.  Setting the margin wide and using objective measures reduces the temptation to occasionally fudge things.

** Again, remove human judgment.  If the die only has 6 or 9 marked, you will occasionally write the wrong number down.  If you don't have a defined order, you will write them down in the order that "looks" most random to you.

It's easy and nothing should be able to go wrong. I mean a lot can go wrong while setting up some sort of space noise receiver.



I would like to test the address before I trust it so I know it's really a valid key. But then I expose the public key and then I doesn't feel 100% secure because of that. This test shouldn't be needed if it was included in Armory because I trust that Amory doesn't fuck things up like I might do.



A single key is fine for me it even feels more secure. Anyway will be looking into your java app and see if it's something for me:)

etothepi, do you plan to add support for "standard" Bitcoin signed messages any time soon (yes, I know this format is not ideal..).
More and more Eligius miners are finding they can't change settings because their signatures fail.
Alternatively, is there a simple way we could have it verify an Armory signature (eg, a CLI program/script with minimal dependencies that just returns 0 or 1)?

Can I ask why you want to use dice as a source of entropy?

You probably don't want to create a single private key but a complete armory wallet with deterministic keys.

I've created a simple java app some months ago that creates Armory paper backup codes from any text input. I've used it to create a deterministic armory wallet from a very long and specific sentence. No need for a paper backup this way. When I'm in trouble I can escape to Nicaragua without any usb-stick and recover my XBT by just buying a laptop, downloading the JAR file from github and feed it with my passphrase.

It may be not 100% what you're looking for because it uses a string as input, but it's open source and you could tweak it for your needs. The code base is very small.

Source code: https://github.com/trapp/brainwallet
Binary Download: https://github.com/trapp/brainwallet/releases/download/1.0.0/BrainWallet.jar

The app works completely offline and doesn't communicate with anything but as always be careful: Read the code and compile it by yourself to be absolutely sure or use it only in an offline environment.