Looks like a good idea to me, I will take a closer look when I find some time.
Thank you! You seem to have a bit of security knowledge. Like the OP says, I pretty much took the scripts posted throughout the forum and put them together! Thanks guys! I was on a mission to find the MOST secure method of storing BTC. 
Topic: Bitcoin Off-The-Grid (BOTG): secure savings script v0.1.1 - page 2. (Read 13277 times)
Looks like a good idea to me, I will take a closer look when I find some time.
I have imported and redeemed successfully the following "vanity" privkey generated by casascius.
Code:
5HtNFUCKiNGPiECEoFGoDDaMNCoCKSuCKiNGSHiT3Viwnu6QQby
1Kv4AcDNkRjhAYvPo3w8RnDw8Jb6Pgq579
0.05 BTC
I Posted a related challenge for when the person makes a typo while writing the privkey down.1Kv4AcDNkRjhAYvPo3w8RnDw8Jb6Pgq579
0.05 BTC
Just so people know, I've tested another 500 generated keys and they all worked too when imported! 
is it possible to take this one step further and initiate an offline transaction? think:
1. generate transaction with offline wallet
2. load transaction to a clean medium (blank dvd, paper, whatever)
3. sneakernet to online computer
4. load transaction
if it's possible, i'd take the time to brush up on the language/source and learn how to do it!
1. generate transaction with offline wallet
2. load transaction to a clean medium (blank dvd, paper, whatever)
3. sneakernet to online computer
4. load transaction
if it's possible, i'd take the time to brush up on the language/source and learn how to do it!
As far as offline transactions go... I believe commands in bitcoind to do all of the following should be added:
1. GET AVAILABLE TRANSACTIONS: caller passes in a list of Bitcoin addresses (presumably of all the private keys it has, but without actually passing the private keys), bitcoind returns a list of all the available spendable transactions on those addresses, including transaction ID's and amounts...
this should be enough for a completely separate offline app to construct valid transactions, assuming it really has independent access to all the private keys involved.
2. FORWARD TRANSACTION TO NETWORK... caller passes in a base64-encoded (for example) raw transaction and bitcoind passes it along as though it had been received from any other peer.
Agreed. It shouldn't be too hard, but the whole transaction building and signing code is in a critical block, so it will take some care to break it out.
is it possible to take this one step further and initiate an offline transaction? think:
1. generate transaction with offline wallet
2. load transaction to a clean medium (blank dvd, paper, whatever)
3. sneakernet to online computer
4. load transaction
if it's possible, i'd take the time to brush up on the language/source and learn how to do it!
1. generate transaction with offline wallet
2. load transaction to a clean medium (blank dvd, paper, whatever)
3. sneakernet to online computer
4. load transaction
if it's possible, i'd take the time to brush up on the language/source and learn how to do it!
As far as offline transactions go... I believe commands in bitcoind to do all of the following should be added:
1. GET AVAILABLE TRANSACTIONS: caller passes in a list of Bitcoin addresses (presumably of all the private keys it has, but without actually passing the private keys), bitcoind returns a list of all the available spendable transactions on those addresses, including transaction ID's and amounts...
this should be enough for a completely separate offline app to construct valid transactions, assuming it really has independent access to all the private keys involved.
2. FORWARD TRANSACTION TO NETWORK... caller passes in a base64-encoded (for example) raw transaction and bitcoind passes it along as though it had been received from any other peer.
is it possible to take this one step further and initiate an offline transaction? think:
1. generate transaction with offline wallet
2. load transaction to a clean medium (blank dvd, paper, whatever)
3. sneakernet to online computer
4. load transaction
if it's possible, i'd take the time to brush up on the language/source and learn how to do it!
1. generate transaction with offline wallet
2. load transaction to a clean medium (blank dvd, paper, whatever)
3. sneakernet to online computer
4. load transaction
if it's possible, i'd take the time to brush up on the language/source and learn how to do it!
5HtNFUCKiNGPiECEoFGoDDaMNCoCKSuCKiNGSHiT3Viwnu6QQby
1Kv4AcDNkRjhAYvPo3w8RnDw8Jb6Pgq579
0.05 BTC
5JokeHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHADmwBca
1HvUDLU1iTfoTCp7KQw6V3Rm9KtZ56NwPS
0.05 BTC
I made an app in Visual Studio that freely converts BTCAddress <--> Pubhash <-- PubKeyHex <-- PrivKeyHex <--> PrivKeyBase58... mainly to increase my understanding of how the algorithms work.
It can generate new addresses at random, and as you can guess, I added a silly feature that allows substitution of characters, where the app would automatically recompute the checksum so that it would be a valid key.
I may publish the source...it happens to be a handy tool.
1Kv4AcDNkRjhAYvPo3w8RnDw8Jb6Pgq579
0.05 BTC
5JokeHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHADmwBca
1HvUDLU1iTfoTCp7KQw6V3Rm9KtZ56NwPS
0.05 BTC
I made an app in Visual Studio that freely converts BTCAddress <--> Pubhash <-- PubKeyHex <-- PrivKeyHex <--> PrivKeyBase58... mainly to increase my understanding of how the algorithms work.
It can generate new addresses at random, and as you can guess, I added a silly feature that allows substitution of characters, where the app would automatically recompute the checksum so that it would be a valid key.
I may publish the source...it happens to be a handy tool.
It looks like it's creating pretty good keys! I've personally created over 100 keys and they were all valid and correct when imported into Bitcoin!
Thanks. Yes, the wording does have to be cleaned up. I was focusing first on the algorithms. Thanks for checking and helping me with this. I think once it's tested some people may want to use it as it provides a pretty high security place to put your BTC. Are you able to get those other transactions I did or did I make a bad key with the older script....
I didn't try to get the other ones... but regardless, if you just import the base58 version of the keys with sipa's import, and see that the matching Bitcoin address showed up in the wallet (since it is computed from the private key), and this could be repeated reliably without exception, I would guess it is overwhelmingly likely that it was correct without the need to do a confirming transaction.
Also I did some experimenting with openssl. Yes, openssl will occasionally generate a 31-byte private key. (it's, of course, a 32-byte private key that happens to start with 00, and the leading zero truncated).
It seems as though this behavior doesn't apply to the public key. The public key as omitted by openssl seems to always start with 04, and no extra "sign" 00 appears if the key material starts with 0x80-0xFF, and nothing is omitted as "leading zeroes", even if the first byte of key material is 00 and the second is 00-7F. I was able to generate a public key starting with "04 00 6b" (where 04 is the standard prefix). So my guess is the public key is safe from weird exceptions.
fixed script. Should always create 64 character long hexes. Will this always make right keys now?
Fingers crossed, one would hope.
I did some playing with it - observed that it rerolls the dice a few times (when the length is not 64 I presume)... and I imported one Base58 key into a wallet with the import patch, and Bitcoin successfully derived the correct address for it.
The next suggestion I might offer would be to abbreviate the text, it seems overly verbose and a bit panicky, and also I'd remove the thanks to grondilu and unk (thanks guys...they've been thanked). I would also be willing to bet that the Base58 key is what's most likely going to be imported by a user, rather than the hex key, and would update the text to reflect that (though I wouldn't remove the hex key altogether). BitBills uses Base58, so does sipa's wallet import... and Base58 has a checksum and guards against typos, where hex does not.
fixed script. Should always create 64 character long hexes. Will this always make right keys now?
Fingers crossed, one would hope.
I did some playing with it - observed that it rerolls the dice a few times (when the length is not 64 I presume)... and I imported one Base58 key into a wallet with the import patch, and Bitcoin successfully derived the correct address for it.
The next suggestion I might offer would be to abbreviate the text, it seems overly verbose and a bit panicky, and also I'd remove the thanks to grondilu and unk (thanks guys...they've been thanked). I would also be willing to bet that the Base58 key is what's most likely going to be imported by a user, rather than the hex key, and would update the text to reflect that (though I wouldn't remove the hex key altogether). BitBills uses Base58, so does sipa's wallet import... and Base58 has a checksum and guards against typos, where hex does not.
fixed script. Should always create 64 character long hexes. Will this always make right keys now?
Quote
There's still a problem, in that any private key that legitimately starts with 0000 thru 007F will still get misprocessed, because it will be spit out as a 62-character string.
The criterion you need to look for is not whether the private key starts with 00, but rather, whether it is exactly 64 characters long. This HAS to work 100% of the time; having it make people lose funds, even if rarely, is inviting disaster and liability.
Anyone now what a great fix would be? I'm off to work and won't have time to look at it for a while... The criterion you need to look for is not whether the private key starts with 00, but rather, whether it is exactly 64 characters long. This HAS to work 100% of the time; having it make people lose funds, even if rarely, is inviting disaster and liability.
Updated to 0.0.2
Some testing being done : https://forum.bitcoin.org/index.php?topic=23521.0
Any useful tips or changes to the script are appreciated!!
Some testing being done : https://forum.bitcoin.org/index.php?topic=23521.0
Any useful tips or changes to the script are appreciated!!
How much entropy does a live cd have after booting?
Good point. I think I'll add something about typing stuff at random and/or moving the mouse around a bunch. Better yet, maybe another script that allows user to type back in what they wrote down (with the original removed off screen so they MUST type from their copy) to make sure they wrote it right.
That's a pretty good idea. Blank the screen and have the user write out what they wrote down. That way they can be sure they wrote it down correctly.
One additional comment,
Having the person write down the private key in wallet import format provides a useful measure of protection against minor transcription errors. If user can't reimport their private key and the checksum fails, it is reasonably possible to make a utility brute force against simple transcription errors (wrong case, characters missing/transposed/etc.) until the checksum can be made to match.
Better yet, maybe another script that allows user to type back in what they wrote down (with the original removed off screen so they MUST type from their copy) to make sure they wrote it right.
Having the person write down the private key in wallet import format provides a useful measure of protection against minor transcription errors. If user can't reimport their private key and the checksum fails, it is reasonably possible to make a utility brute force against simple transcription errors (wrong case, characters missing/transposed/etc.) until the checksum can be made to match.
Better yet, maybe another script that allows user to type back in what they wrote down (with the original removed off screen so they MUST type from their copy) to make sure they wrote it right.
How much entropy does a live cd have after booting?
I guess the question really boils down to where does OpenSSL get its random numbers from.
EDIT: the answer looks like /dev/urandom. And apparently, you can increase entropy by sending random data to /dev/random. Maybe the user can be asked to mash on their keyboard, and that be sent to /dev/random. Just going by what I read on Wikipedia, no guarantee to accuracy.
How much entropy does a live cd have after booting?
Jump to: