vanity private keys

[coblee]

Let's say I'm super paranoid and wanted to store a hard copy of my private key in a safe and I'd like to keep a portion (the vanity part) of my private key in memory. So even if someone breaks into my safe and sees the partial private key, they still won't be able to brute force my actual private key.

Private keys are 51 length base 58 characters, right?

How safe are each of these solutions?
1) Use the first or last x number of characters as vanity part. 186YpATQehFZwhVpnGzVTKb8VLtmeBITCOINRULES
2) Have the vanity part embedded inside and remember the location. 186YpATQeBITCOINRULEShFZwhVpnGzVTKb8VLtme
3) Have 2 vanity sections and remember both locations. 186YpATQeBITCOINhFZwhVpRULESnGzVTKb8VLtme

Obviously the last method is the most safe. How safe is it? And are either of the first 2 good enough?

[1715569033]

1715569033

[1715569033]

1715569033

[1715569033]

1715569033

[1715569033]

1715569033

[JoelKatz]

1) Use the first or last x number of characters as vanity part. 186YpATQehFZwhVpnGzVTKb8VLtmeBITCOINRULES
2) Have the vanity part embedded inside and remember the location. 186YpATQeBITCOINRULEShFZwhVpnGzVTKb8VLtme
3) Have 2 vanity sections and remember both locations. 186YpATQeBITCOINhFZwhVpRULESnGzVTKb8VLtme
Obviously the last method is the most safe. How safe is it? And are either of the first 2 good enough?

I would say they're all comparable. Just realize that every bit of random data in your private key you replace with less-random data means your key is that much weaker.

If you want to be super paranoid, you can do this:

1) Compose a string consisting of a random 256-bit portion and a memorized portion.
2) Store the random 256-bit portion in your vault.
3) Use as your private key the SHA-256 hash of the two portions.

This way, your key still has 256-bits of pure randomness in it, so you haven't made it any weaker than a normal private key. And now an attacker who gets the 256-bit portion still doesn't know a single bit of your private key and must brute force the memorized portion.

[samr7]

Let's say I'm super paranoid and wanted to store a hard copy of my private key in a safe and I'd like to keep a portion (the vanity part) of my private key in memory. So even if someone breaks into my safe and sees the partial private key, they still won't be able to brute force my actual private key.

Private keys are 51 length base 58 characters, right?

How safe are each of these solutions?
1) Use the first or last x number of characters as vanity part. 186YpATQehFZwhVpnGzVTKb8VLtmeBITCOINRULES
2) Have the vanity part embedded inside and remember the location. 186YpATQeBITCOINRULEShFZwhVpnGzVTKb8VLtme
3) Have 2 vanity sections and remember both locations. 186YpATQeBITCOINhFZwhVpRULESnGzVTKb8VLtme

Obviously the last method is the most safe. How safe is it? And are either of the first 2 good enough?

If the attacker has knowledge of the associated bitcoin address, the problem is much like cracking a hashed password.  Each test will require more compute power than a single round of a common hash function, but a lot less than 1024 rounds of MD5.

In the first one, your removed code letters specify the lower 32 bits of the encoded key, which are the checksum.  To even create a private key like this, you would need to search for upper code letters that result in your desired checksum.  The code letters in excess of those making up the checksum are the only part an attacker would need to guess.

The second requires the attacker to guess the code letters, as well as where they are located in the key.

The third requires the attacker to guess two groups of code letters and all permutations of where they might be located, which is a few more orders of magnitude harder.

[pc]

I would think the best/easiest plan would just be to generate a random private key as normal, and just encrypt it in your vault using your chosen password.

[jackjack]

See that: https://bitcointalk.org/index.php?topic=33683.0

[makomk]

If the attacker has knowledge of the associated bitcoin address, the problem is much like cracking a hashed password.  Each test will require more compute power than a single round of a common hash function, but a lot less than 1024 rounds of MD5.

In the first one, your removed code letters specify the lower 32 bits of the encoded key, which are the checksum.  To even create a private key like this, you would need to search for upper code letters that result in your desired checksum.  The code letters in excess of those making up the checksum are the only part an attacker would need to guess.

The second requires the attacker to guess the code letters, as well as where they are located in the key.

The third requires the attacker to guess two groups of code letters and all permutations of where they might be located, which is a few more orders of magnitude harder.

This is basically correct apart from one thing: if you leave the checksum digits the hacker can reject the majority of their hacking attempts after just doing a single round of SHA256, which is much cheaper than having to compute the address or public key their guess maps to. Ideally you should remove the checksum totally and insert the vanity section somewhere in the rest of the private key, but that's kind of tricky to reverse.