How Secure Is Splitting A Bitcoin Private Key?

Question

NOTE: This question cannot be posted to Bitcoin SE because it will not render there due to the mathematical notation. Since the mathematical notation is part of the question, this is the more appropriate forum to post on, with tag 'cryptocurrency'.

I wonder how secure it is to split up a printed Bitcoin private key into parts and keep the parts in separate secure physical locations, such as safe deposit boxes, like the Winklevoss twins.

I am considering a standard Base58Check encoded compressed WIF-format Bitcoin private key of length 52, starting with a K or L.

Imagine it was cut up into 4 pieces and 3 were found. To guess the last 13 base58 characters by brute force would require $58^{13}$ operations, taking time :

$$t = t_0 \left(\frac{\Delta t}{C}\right) \hspace{1em} \mbox{(years)} $$

where $t_0 \simeq 2.7$ million, $\Delta t =$ time per operation (per single core) in nanoseconds, and $C =$ number of cores running in parallel, where each operation requires :

1. form the full 52 char key
2. base58 decode it to 38 byte binary string
3. check the checksum in the last 4 bytes equals first 4 bytes of the double SHA256 hash of the first 34 bytes
4. if yes for step 3) verify private key maps to desired bitcoin address

To guess k more characters than that would take :

$$t = t_0 \left(\frac{\Delta t}{C}\right) \cdot 58^k \hspace{1em} \mbox{(years)} $$

Thus for splitting into 2 pieces ($k = 13$), guessing one half of the key would take :

$$t = 2.2 \times 10^{29} \times \left( \frac{\Delta t}{C} \right) \hspace{1em} \mbox{years} $$

However how low a $\Delta t$ could be achieved in practice ? And what kind of a value could $C$ realistically have, the number of cores that could be marshalled?

In particular I wondered whether splitting into 2 pieces is absolutely secure. And how long into the future it would be before that was no longer the case.

---

Below are some test partial private keys (in compressed WIF Base58Check format), the unknown characters are displayed as dashes. If anyone wants to try and hack them please post up your results. Some empirical data on typical $\Delta t$ values (time per brute force operation) for different software scripts and hardware specs would be helpful.

Test 1 - Find Right 13
----------------------
Private key :
KzVQ743N6jkKFKsmsdsf9nmx7D1vdTeobc2eFSF-------------
Bitcoin address :
1BhjTbu5iWEgkG9HxHqoDkagvdUDh2UYPz
Test 2 - Find Right 26
Private key :
L4UArgExSB4bdtC5SghFuPQghk--------------------------
Bitcoin address :
19QPobhrbQ28UsCVGbJKijnmGHFEAJ8FJK
Test 3 - Find Left 13
Private key :
-------------c9Dkk3UKidxmupMtwHFYLxZNjbeq2SKd2eUWcRh
Bitcoin address :
1P15r2MrtCYec7DpqfGN3rn3BqLYN7E6a1
Test 4 - Find Left 26
Private key :
--------------------------VVWWsyvpetNHhiaLtBcZ3RkBHg
Bitcoin address :
1HVhAuVV5K8rFSiFMqNJZrT72u649bvtBV
Test 5 Find 2nd Quarter 13
Private key :
L4gzpA7sUULxp-------------Y6LQWCgveEMNuCdnao9GFEhiyK
Bitcoin address :
1LDtdQPgj3HacPFCBLrdFPausLMRTBRFk6
Test 6 Find 3rd Quarter 13
Private key :
Kyrs2tSXduPtE6sMjDMnx2yscm-------------H3KwLimK92vDe
Bitcoin address :
16JGYPqog44EiM36uAVkam5j2ereJsmEGX

Answer 1

This answer, and the question, assume that the public key is not available to the attacker. This is unusual in cryptography, but a possibility in Bitcoin, where the hash of the public key (known as address) is enough for a so-called Pay-to-Public-Key-Hash.

To guess the last 13 base58 characters by brute force would require $58^{13}$ operations

Yes, but there's educated brute force.

The "standard Base58Check encoded compressed WIF-format Bitcoin private key" is a 52-characters string encoding per Base58 of the nearly random 32-byte ECDSA private key $d$ for curve secp256k1, plus two fixed bytes and a checksum (the first 4 bytes of the SHA256d^(*) hash of the first 34 bytes), arranged as:

    80_h   [32-byte private key]   01_h   [4-byte checksum]

In this context Base58 reduces to the usual positional numeral system with base 58 instead of 10 for decimal, and "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz" instead of "0123456789". Everything is big-endian.

The first $52-k$ characters of the WIF-encoded private key disclose an integer $d_\min$ such that $d_\min\le d<d_\max$ with $d_\max-d_\min\lesssim\Delta_k=\left\lceil58^k/2^{40}\right\rceil+1$.

If we lack the right $k=13$ characters, we have narrowed $d$ to an interval of width $\Delta_k\approx2^{36.2}$ candidates. We can test one candidate by deriving the public key, hashing it and comparing to the 20-byte known hash (the decoded address). The expected cost is dominated by $2^{35.2}$ point additions (when we move to the public key of the next candidate by adding $G$), SHA-256 and RIPEMD-160. This is feasible with a single PC. I throw in $\Delta t<1\,\text{ms}$ without justification.

Things are more difficult for other segments. For $k$ unknown characters in the center, it's possible to leverage the known 01_h to reduce to $58^k/2^8$ candidates, a saving by a factor of 256 compared to what the question considers. And (as pointed in the question) it's possible to leverage the checksum to screen out all but one candidate in about $2^{32}$ with only two SHA-256 per candidate, which is an appreciable saving.

There's a large further saving possible if the missing characters are on the left. That's evidently at least by a factor of 26 since the left character is K or L, but it gets much better, perhaps 392.

---

How Secure Is Splitting A Bitcoin Private Key?

Not much, as shown in this answer. And it gets MUCH worse if the public key is known, as shown in this other answer.

---

^(*) SHA256d is two SHA-256 chained.

Answer 2

If the public key is not known then it appears half a private key presently cannot be hacked in feasible time. For guessing a right half, a time of $2.04 \times 10^{20}\ \mathrm{years}$ is needed to check every possibility, assuming $\Delta t = 1 \mathrm{ms}$ (time per brute force operation), using the formula in fgrieu's answer, and $1 \mathrm{ns} = (10^{-16} / 3.15)\ \mathrm{years}$, each operation comprising an secp256k1 point addition, a SHA256 hash, a RIPEMD160 hash, and comparison with Bitcoin address. For guessing left half there are 3 operations, (1) extract byte 4 and compare with $0x01$ - repeated $N_1$ times $(N_1 = 2 \times 58^{25}$ due to the known 1st char $K/L$), (2) double SHA-256 hash and compare with 4-byte checksum - repeated $N_2$ times $(N_2 = 1/2^8 \times N_1)$, and (3) compute public key and its 20-byte hash and compare with Bitcoin address - repeated $N_3$ times $(N_3 = 1/2^{32} \times N_2)$. Assuming $\Delta t = 1 \mathrm{ms}$ this gives : $0.77 \times 10^{31}$, $3.01 \times 10^{28}$, and $7.01 \times 10^{18}\ \mathrm{years}$ respectively (which would be adjusted once better $\Delta t$ estimates were available). Each of these individually seems non-feasible even with $\Delta t = 1 \mathrm{ps}$. Algorithms such as Baby-Step/Giant-Step and Pollard's rho mentioned in this answer to this related question which solve the discrete logarithm problem can only assist an attack if the public key is known which is not the case in Bitcoin since a Bitcoin address only contains a hash of the public key. The best chance to perform a hack would be a large mining farm. I have updated the question with a challenge to hack some test keys.