Bitcoin Forum
December 05, 2024, 04:57:21 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: vanity private keys  (Read 1273 times)
coblee (OP)
Donator
Legendary
*
Offline Offline

Activity: 1654
Merit: 1354


Creator of Litecoin. Cryptocurrency enthusiast.


View Profile
August 01, 2011, 11:02:08 AM
 #1

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?

JoelKatz
Legendary
*
Offline Offline

Activity: 1596
Merit: 1012


Democracy is vulnerable to a 51% attack.


View Profile WWW
August 01, 2011, 12:15:04 PM
 #2

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.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
samr7
Full Member
***
Offline Offline

Activity: 140
Merit: 430

Firstbits: 1samr7


View Profile
August 01, 2011, 12:25:30 PM
 #3

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
Sr. Member
****
Offline Offline

Activity: 253
Merit: 250


View Profile
August 02, 2011, 01:04:34 PM
 #4

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
Legendary
*
Offline Offline

Activity: 1176
Merit: 1280


May Bitcoin be touched by his Noodly Appendage


View Profile
August 02, 2011, 03:08:32 PM
 #5

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

Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2
Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
makomk
Hero Member
*****
Offline Offline

Activity: 686
Merit: 564


View Profile
August 05, 2011, 04:13:00 PM
 #6

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.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!