asyn
Newbie
Offline
Activity: 25
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 25, 2013, 06:23:13 PM |
|
I just updated to OSX 10.9 and now my armory app is broken with this error in the console... % /Applications/Armory.app/Contents/MacOS/ % ./Armory Traceback (most recent call last): File "ArmoryQt.py", line 26, in <module> File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/socket.py", line 47, in <module> import _socket ImportError: dlopen(/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_socket.so, 2): Symbol not found: __PyInt_AsInt Referenced from: /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_socket.so Expected in: flat namespace in /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_socket.so
Looks like I just have to install something can someone point me in the right direction? Is this the .dmg/app that was downloaded from our website? Or did you follow Red Emerald's instructions to build it yourself? Because that's clearly referencing system libraries, which I'm pretty sure the .dmg is not supposed to do (it's supposed to be totally isolated). Perhaps that's a hint for why it doesn't work on some systems? I have some stuff from picobit to try, which may improve the OSX compatibility. But I'm still getting caught up with some other things. Maybe someone else wants to try what he produced and give me a review? ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) My new Mac Mini isn't sufficiently setup to try it yet. Yes it is the application downloaded from your site. I can confirm this issue. DMG from Armory Website used to function properly in 10.8 but I get the same error after updating to Mavericks.
|
|
|
|
chrisrico
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 25, 2013, 06:50:14 PM |
|
I would not trust that I got the information into /dev/random correctly and that Armory really picked it up. I would really appreciate some sort of user interface inside of Armory that allowed me to input dice results (In expert mode ofc).
Can't you just convert dice results to a private key yourself and import that into Armory?
|
|
|
|
robanswe
Newbie
Offline
Activity: 24
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 25, 2013, 08:56:23 PM |
|
Can't you just convert dice results to a private key yourself and import that into Armory?
Now I feel really lazy but is there any simple way to do this? Any offline open source tools available to do this? Or how exactly do I convert dice results into a private key?
|
|
|
|
asyn
Newbie
Offline
Activity: 25
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 25, 2013, 09:30:55 PM |
|
Can't you just convert dice results to a private key yourself and import that into Armory?
Now I feel really lazy but is there any simple way to do this? Any offline open source tools available to do this? Or how exactly do I convert dice results into a private key? 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/brainwalletBinary Download: https://github.com/trapp/brainwallet/releases/download/1.0.0/BrainWallet.jarThe 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.
|
|
|
|
chrisrico
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 25, 2013, 10:05:24 PM |
|
Now I feel really lazy but is there any simple way to do this? Any offline open source tools available to do this? Or how exactly do I convert dice results into a private key?
Can I ask why you want to use dice as a source of entropy?
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 26, 2013, 04:49:55 AM |
|
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)?
|
|
|
|
robanswe
Newbie
Offline
Activity: 24
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 26, 2013, 09:40:01 AM |
|
Can I ask why you want to use dice as a source of entropy?
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. Get two 16 sided die, roll 32 times and each pair is the part of the hexdecimal private key. If I remember correctly that is how you do it.
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. 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/brainwalletBinary Download: https://github.com/trapp/brainwallet/releases/download/1.0.0/BrainWallet.jarThe 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.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:)
|
|
|
|
kjj
Legendary
Offline
Activity: 1302
Merit: 1026
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 26, 2013, 01:28:33 PM |
|
Can I ask why you want to use dice as a source of entropy?
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. 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.
|
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
dserrano5
Legendary
Offline
Activity: 1974
Merit: 1029
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 26, 2013, 02:30:38 PM |
|
That makes me wonder, isn't it "easier" to just toss a coin 256 times? Sure, you may get bored in the process ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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.
|
|
|
|
kjj
Legendary
Offline
Activity: 1302
Merit: 1026
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 26, 2013, 03:27:28 PM |
|
That makes me wonder, isn't it "easier" to just toss a coin 256 times? Sure, you may get bored in the process ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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. 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.
|
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
chrisrico
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 26, 2013, 06:29:09 PM |
|
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. If you have the correct number of bits, there is no such thing as an "invalid key".
|
|
|
|
picobit
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 27, 2013, 09:32:33 AM |
|
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. If you have the correct number of bits, there is no such thing as an "invalid key". 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.
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3724
Merit: 1360
Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 27, 2013, 02:32:45 PM |
|
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.
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 27, 2013, 04:09:24 PM |
|
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.
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)
|
|
|
|
kjj
Legendary
Offline
Activity: 1302
Merit: 1026
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 28, 2013, 01:19:37 AM |
|
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.
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.
|
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 28, 2013, 11:20:18 PM |
|
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 sha2562() or HMAC() is totally sufficient for converting arbitrary data to a private key, as long as that data has sufficient entropy.
|
|
|
|
justusranvier
Legendary
Offline
Activity: 1400
Merit: 1013
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 28, 2013, 11:28:14 PM |
|
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 28, 2013, 11:32:27 PM |
|
I actually made my own device, using my recent obsession with 3D printing: http://www.thingiverse.com/thing:167019I 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).
|
|
|
|
maaku
Legendary
Offline
Activity: 905
Merit: 1012
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 28, 2013, 11:33:57 PM |
|
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'm an independent developer working on bitcoin-core, making my living off community donations. If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
|
|
|
|