most secure savings wallet: NO wallet

[bitplane]

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 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.

[1714782554]

1714782554

[1714782554]

1714782554

[MrJoshua]

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

[symbian]

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

[molecular]

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

Is 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef really a valid privkey?

importprivkey says it's not.

#> bitcoin importprivkey 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef
error: {"code":-5,"message":"Invalid private key"}

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

[jackjack]

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

Is 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef really a valid privkey?

importprivkey says it's not.

#> bitcoin importprivkey 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef
error: {"code":-5,"message":"Invalid private key"}

Afaik, importprivkey only accepts base58 privkeys

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

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

[molecular]

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

Is 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef really a valid privkey?

importprivkey says it's not.

#> bitcoin importprivkey 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef
error: {"code":-5,"message":"Invalid private key"}

Afaik, importprivkey only accepts base58 privkeys

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

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

I see. Thanks for clearing that up.

[casascius]

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

[samr7]

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

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.

[jackjack]

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

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

[odolvlobo]

To those saying a pass-phrase based key can't be used because it lacks entropy have obviously never heard of Password Based Key Derivative Functions

http://en.wikipedia.org/wiki/PBKDF2

To those that haven't heard of key derivitives they work because instead of taking a hash of the passphrase (i.e. "This is my secure bitcoin passphrase"),  you take a hash of the hash of the hash of the hash of the hash of hash ..... (n iterations later) of the passphrase.

Also a random salt is chosen at the time of password generation and is added to each round of hashing. 

To make it brute force proof one simply needs to pick a large enough n so that it takes a "non trivial" amount of time to hash one password.

Current top of line GPU can perform < 1 GH/s. 
So you make n = something in the magnitude of 10 million.


An example program would prompt the user for 4 randomly chosen words (w1,w2,w3,w4) and a 4 digit number (p).  (You could have the program not generate a key for words which are too common to improve security).
passphrase = w1+w2+w3+w4
p = salt
n = p * 2^12  (the 2^12 is a constant to match all possible 4 digit p's to a n in the range we need (~10M so it takes a GPU a "non-trivial" amount of time to complete).
 
Now simply run a key derivative function which uses a pass-phrase of "w1+w2+w3+w4" iterates n times with each round salted with p.
...
a single 1 GHash/s GPU making 30 attempts per second would take nearly 11 million years to try all possible combinations of passwords and salts.
However that is just one GPU.  What if deepbit pool tried to brute force the key?  With 5THashes/s of computing power it would only take deepbit ~3,400 years.  Another way to look at it is the entire deepbit pool would need to work for 34 years 24/7/365 just to have a 1% chance of breaking the private key.

To regenerate the private key in the future the user would simply need to remember the 4 words and 4 digit pin.  Hopefully this gets some people thinking.

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.

[Boussac]

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

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.

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 ?