Bitcoin Forum

I'm sure a lot of you know of this, but let me explain a method for storing your savings that is quite secure and hard to screw up:

The idea is to use no wallet. All you need to "store" bitcoins is an address. To use these coins, you need the associated private key.

So why not do away with all the wallet.dat securing and fiddling with swapping wallets, securely deleting plaintext versions and all that and just generate a key using vanitygen (https://bitcointalk.org/index.php?topic=25804.0)?


Now simply send your savings to that Address (1JBhAaDAFHRuUjyVrjte6XwSwXpTmGsCSt)

All you need to store is the Privkey (5HyBZhJu2UgjA2nUVSF9infL8KMEeCgSguEz8FXoP2FZGG76NiW). You need to do this securely, of course (print it out, write down, encrypt and mail to friends, put on super-secret usb-drive, or use some other method)

Now when you want to get at your savings later (or verify it's working), you can import the key into any wallet.dat using either the importprivkey rpc command of the bitcoin client (currently still sipa:showwallet patch necessary) or using pywallet.

Additional measure for enhanced security: generate the address(es) on a secure machine with no network connection, known to be non-infiltrated.

Any problems with that approach?

sounds good but will be even better once the mainline client can import the privkey :)

would be funny if your privkey only existed as a hand-written note.

actually, given 10 or 15 minutes you could probably just memorize it.

Really smart, I love it
Just one thing: the priv key has been written somewhere

[NSFNewbies]

Instead you can create yourself your privkey (at least the hex one, 64 characters long, I don't know if all base59 ones are valid they are not because of the checksum) using your own pattern that you know by heart, thus no need to write it
E.g. 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef for 19ffB4HttNCHfY1t3YuErEytCspyHyVMwv

Or if you prefer learn sentences: md5('I love bitcoin').md5('Paypal suxxx') for 1G1b4mbjaCYNxsZJyaWV9qyE5cFVhZxBcy

Or even substr(md5('I love bitcoin'), 0, 14).md5('Paypal suxxx').substr(md5('I love bitcoin'), 14, 18)  ;D

Wouldn't getting your private key stolen be the same as getting your wallet.dat stolen?

just for fun i sent you 0.02 btc to that imaginary address :D ...you'll have to now import it quick before someone else does ;)

This is very dangerous and very stupid, and I'm talking about sending BTC to an anonyomus Nevis LLC level stupid here.

The current bitcoin market cap is $90 million USD. Even if just 1% of bitcoiners take your advice, that's still $900,000 USD free money for anyone capable of setting up a GPU farm (a rare talent, I might add ;D). Human chosen passwords only have 1.0 to 1.5 bits of entropy per letter. Your examples contain less than 30 bits of entropy, and that's not taking into account the hacker will populate their dictionary with frequently appearing words from this forum. Compared to the ~256 bits of entropy in real Bitcoin keys, your method would generate private keys that are 2^226 ~= 1.07839787 × 10^68 times easier to brute-force.

I nearly lost them, just figured out my wallets seem broken ;D I had to pay fees for not being stolen but thanks :)

That's why I added the substr trick...
If people are stupid enough to just use md5.md5 that's their problem...
Everyone who is savvy enough to know how to concatenate two md5's know they MUST use salts and tricks like that too...
1KJvYREkZxEgDczTKoEtvrhfkALsFsWKRa: my two passphrases are 'jackjack' and 'iamzill', come at me bro

Yes.

This is a great possible addition to secure bitcoins 'offline', problem is, it's very user-unfriendly.
These functions should be in the normal client, using a nice interface, instead of the need for 2 or more different command-line tools.

For your post, the message of iamzill does apply
If it's integrated in the client, the functions will be known by attackers and bruteforce will be far more easy
So either the client integrates thousands of different functions of the passphrases and user must learn which one he used, or that great idea will be reserved for people willing to study a little bit

Also, no need for command line: http://www.miraclesalad.com/webtools/md5.php

or :-
1) get 2 or more 8GB USB stick and install a fresh copy of ubuntu 11.04
2) install the bitcoin client
3) download the blockchain and generate a couple of addresses
4) unmount and duplicate the USB stick [a couple of times]
5) store sticks somewhere physically safe
6) send coins to the address you have generated in #3
....

when you need to access coins
1) clean boot the usb stick
2) download the blockchain [either let the client do it or do it the sneaky way]
3) send coins to your current useful address [make sure you get it confirmed]
4) shutdown USB version and store it away safe
...

installing security patches for Ubuntu etc and testing to see that it works on a few machines may be useful
YMMV

I'm sorry but that trick only adds a negligible amount of entropy, which is negligible. It doesn't matter what kind of tricks you use, whether you end up with 20 bits of entropy or 200 bits of entropy, you're still greatly weaking the system. Suppose by using lots of passwords, lots of substr, repeated hashes, and salts and you end up with 250 bits of entropy, that's still only 1.5% of the entropy of a real key. Is it worth it to go through all that custom code and memorization just to end up with a private key that's 64 times weaker? Isn't it much safer just printing out the key pair like OP suggested or burning the wallet.dat on a CD?

As for your challenge, you missed my point about mentioning the $900,000 USD reward money. I'm not saying it's possible for an attacker to target your specific password. In fact, I can almost gurantee your address 1KJvYREkZxEgDczTKoEtvrhfkALsFsWKRa won't be brute-forced. I was claiming that if enough people saw your post and adopted your method, the attacker can steal from those people collectively, since they all share the same tiny keyspace.

Sorry if I come off as too critical, but I'm just trying to make sure bitcoin stays secure. If lots of people spoke out critically against mybitcoin in the first place then it wouldn't have ended up the way it did. I believe the only to way to ensure the collective security of the bitcoin eco-system is to harshly criticize any non-secure algorithm, organizational structure, and business practice that gets suggested. Every security compromise and every fraud devalues everyone's bitcoins, and more importantly threaten the future of this cryptographic currency.  

I'll stress it again, it's almost perfectly for safe for jackjack to use his method for himself. But if somehow this method ends up being implemented in the official client and thousands of people start using it, then the bruteforcing will begin and people will lose money and see it as a bitcoin security hole when it clearly isn't. I'm only criticizing it so that this worst case scenario doesn't happen. You're more than welcome to use it on your own.

@jackjack:

Your method's issue is about collisions. With people choosing password eventually some will pick the same password set. (even if a guy just testing password: password).

imaginary? it's quite real.

importing is not sufficient, I'd also have to send the coins on.

Sure it's less secure but at least people using that won't lose/delete/formatc:/etc their wallets definitely and cry "I deleted my wallet.dat, I can't recover my coins, it's Bitcoin's fault" anymore
I think that if each person choses his own function and knows they are weakening his safety, it's remains mostly ok
The problem is indeed if people use it without understanding what they do or if the functions are in implemented in the client
I didn't understand your first post like that

I'll add a NSFNewbies tag in my post :)

i just meant that the private key was created using his imagination, and yes you're right it's a race to spend, not a race to import. jackjack has now spent the 20 millies anyway.

Take the polish exchange for example. The owner basically said "Amazon lost my wallet.dat, I can't recover my coins". Then someone suggested to take Amazon harddrive offline and recover wallet.dat.

When people use "Sorry guys, I kinda forgot my exact password, hashing algorithm, and substr offset during my vacation.", I'm afraid someone will suggest taking the owner offline and water-board him until the password, hashing algorithm, and substr offset is recovered.

What about a sufficiently long password? For example: "Twas brillig, and the slithy toves Did gyre and gimble in the wabe; All mimsy were the borogoves, And the mome raths outgrabe" contains more than enough entropy (if I'm doing it right)

I think the solution to the "secure your wallet problem" is to have a real device. A real virtual wallet. It would be a small device with wifi, a screen and a few buttons with the unique purpose of running a bitcoin client.

Has anyone thought of this? I think it would be really cool if someone starts manufacturing a device like this.

OP's method works, but it will never be user friendly enough...

I wouldn't recommend a full quote from a very famous piece of literature either - might have enough entropy word-wise if you make it long enough but it would no doubt be ranked among much lower entropy passwords in any sensibly crafted password cracking wordlist. An adversary having some knowledge about your person might even limit the genres of possible literature etc...

Yeah, it would have to be something obscure. One of my previous password policies was to use ironic quotes from "The Complete Book of Locks and Locksmithing" as my key.

This has already been discussed here:

https://bitcointalk.org/index.php?topic=29187.0

and here:

https://forum.bitcoin.org/index.php?topic=28877.0

Passphrase entropy is not exactly the problem, since most people will likely have a low entropy password on their encrypted wallet file too.  It's the fact that the keyspace of a passphrase wallet can be searched without access to your encrypted wallet file. However, I'm still of the belief that passphrase based wallets have interesting properties that are worth investigating further as discussed in the first link above. Also it's not good enough to bruit force the private key, it is only useful if there is money still in it, meaning for short delay transactions this system could still be effective even against a well funded attack.

Note that all the tools for doing this exist now.

j

P.S. Some people seem to miss the fact that "passphrase" is a term of art with a specific meaning, so just to be clear: http://en.wikipedia.org/wiki/Passphrase

Doesn't topic started citing Bitcoin wiki https://en.bitcoin.it/wiki/How_to_set_up_a_secure_offline_savings_wallet ?

Is 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef really a valid privkey?

importprivkey says it's not.


I didn't think you could just use any 256 bit number as private key. Please, someone knowledgable clear this up for me.

Afaik, importprivkey only accepts base58 privkeys


You can use any 256bit number as private key, except 0

I see. Thanks for clearing that up.

YOu can use Casascius Bitcoin Utility (for Windows) to convert between base58 and hex.

This is true.  However, there are a fixed number of points on each elliptic curve, and for the secp256k1 curve used by bitcoin, there are fewer than 2^256:

0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

This value is equivalent to 0 and isn't valid.  However, one plus this value is equivalent to 1.  Don't use anything equal or larger than this value as a private key.

Thanks for this info!
I'll add a warning in pywallet

Sorry for necroing this thread, but I couldn't leave the previous post as the last post. It makes some bad assumptions. First, while it would take a lot of computing power to crack a single private key generated by this method, it would take much less effort to find a private key generated by this method if a million keys were generated. That is the basic flaw in using any kind of algorithm to generate a private key from a smaller key. Second, given the constant exponential increase in computing power, all the estimates above will be cut by a factor of 100 in only a decade or so.

The only real criteria for the safety of a private key algorithm is whether or not it is more efficient to mine BTC or to look for the private keys. If the method above were to become popular, then it could be more efficient to look for the generated private keys than it would be to mine, and the algorithm would not be safe.

This value is called the order of the base point G of the curve: the smallest integer n > 0 for which nxG = O where O is the identity element of the additive group, meaning O is a point such that O+P = P for any P in the group.
Typically, in ECDSA, O can have an infinite y coordinate (for some elliptic curves).
Therefore I would not say that the order of G is equivalent to zero because it would lead people to think that the operand of the group is some kind of arithmetic addition when in fact it is not (it is a geometric addition).

Thoughts ?