<p>There are two problems with your approach. The second one's more difficult to solve than the other.</p>
<h2>Problem 1</h2>
<p>While it would take me a 100 million years to brute force the key <code>1 2 3 4 5 6 7 8 9</code>, if I know two thirds of the key, it doesn't take just 1/3 the time, but a cube root of the time, meaning that I might actually be able to guess it.</p>
<h3>Giving everyone a part of the key without making bruteforce faster</h3>
<ol>
<li>Instead, you generate 3 totally random strings of bytes as long as the key. We'll call these R1, R2, and R3.</li>
<li>We'll call the private key K, and the clients, C1, C2, and C3.</li>
<li>To C1, you give R1, and R2 ^ K. (^ is shorthand for <a href="http://en.wikipedia.org/wiki/Exclusive_or" rel="nofollow noreferrer">XOR</a>)</li>
<li>To C2: R2, R3 ^ K</li>
<li>To C3: R3, R1 ^ K</li>
</ol>
<p><em>Example</em>: If C1 and C2 put their heads together, they could combine R2 and R2 ^ K. This is important, because R2 ^ R2 ^ K = K<br />
<em>Space requirement</em>: Given that n = number of people, and m = maximum number of people  abstain, you need n!/m!/(n-m)! ciphertexts. Okay for 3 people, starts to get unwieldy for 10.</p>
<h2>Problem 2</h2>
<p>When generating the key in the first place, somebody needs to know the full private key before they split it up. In other words, you need a trusted third party. To get around this, you need to do something called <a href="https://en.wikipedia.org/wiki/Distributed_key_generation" rel="nofollow noreferrer">Distributed Key Generation</a>. I'm not sure if this can be done for ECDSA. <a href="https://ieeexplore.ieee.org/document/5626958" rel="nofollow noreferrer">This paper</a> looks encouraging based on the abstract, but I can't see the whole article.</p>
<h3>Multi-signature transactions</h3>
<p>This is a much more scalable and secure system. Unfortunately, it's not really ready for real-world use yet.</p>

CC BY-SA 3.0
2013-01-19T21:08:00.020Z
Thanks for going into the detail and providing an alternative better method. I'm waiting for multisig but wouldn't mind having something in the intertim and get the rest of the stuff around it done and then just replace with multisig when it hits prime time.
Richard Green
CC BY-SA 4.0
2013-01-18T17:34:16.153Z
2022-04-18T17:04:37.360Z
2022-04-18T17:04:37.360Z
Nick ODell
<p>Your proposed solution would now work without a third party knowing the complete key. It is impossible to derive a valid public key from three partial private keys in the way you described.</p>

<p>On the other hand, it is possible to create n-out-of-n multisig addresses using <a href="https://bitcointalk.org/index.php?topic=90587.0" rel="nofollow">split-key vanity addresses</a>. However, this can have an issue with coins getting lost and one party being malicious and stealing all the coins once they get their hands on all N keys.</p>

CC BY-SA 3.0
2013-01-15T10:08:42.397Z
2013-01-15T10:08:42.397Z
ThePiachu
<p>You should follow Gopoi's advice and use multisig. There are a few problems with your system. The first problem is how two people share their password. One of them could lie and get the whole password. Even if they share the right values, they need to agree to send a transaction which divides the funds. The user sending the transaction could cheat and send it all to his/her account. </p>

<p>Also, notice the security is much worse. I'm not sure what you mean by 1/3 of the security. If you refer to bits/digits this is right, but this is much less security. In your example, instead of trying all values from 0 to 999999999, any of the participants can guess the password with only 1000 attempts (they just need to fill three gaps). In Bitcoin, instead of a key with around 256 bits, you get about 86 bits of security. This seems decent enough for short times, but is much less secure. </p>

<p>With multisig the users will only sign a transaction they agree with. They know what they get, the key is as strong as in any other transaction and it is easier to scale to more than three users.   </p>

CC BY-SA 3.0
2013-01-14T16:45:23.287Z
2013-01-14T16:45:23.287Z
halftimepad
<p>The way you address this you should use the script CHECKMULTISIGVERIFY with 3 different key provide within one transaction each party having his own key. </p>

<p>See <a href="https://en.bitcoin.it/wiki/Contracts#Example_2%3a_Escrow_and_dispute_mediation" rel="nofollow">here</a> for an example that resemble with what you were asking.</p>

CC BY-SA 3.0
2013-01-12T03:34:22.723Z
2013-01-12T03:57:59.247Z
2013-01-12T03:57:59.247Z
Gopoi
<p>In the situation that you want no individual to have the complete private key, but you do want  to share the complete key between 3 individuals, of which any 2 can construct the complete key, what is the downside from doing something like this:</p>

<p>Orig key = 1 2 3 4 5 6 7 8 9 (abbreviated for demo)</p>

<p>key 1 = 1 2 _ 4 5 _ 7 8 _</p>

<p>key 2 = 1 _ 3 4 _ 6 7 _ 9</p>

<p>key 3 = _ 2 3 _ 5 6 _ 8 9</p>

<p>obviously any 2 keys would construct the entire key again.</p>

<p>Apart from the decrease of key strength to 1/3 of the original, are there any other potential issues ? </p>

<p>This would be used for "short term" escrow accounts where, in the case of a "winner takes all", the escrow would just communicate their key to whichever counterpart won. If the escrow failed to send, then the counterparties could choose another (trusted) escrow and transfer the funds to them.</p>

<private-key>
Is this an ok "poor man's 2 out of 3" key solution?
Richard Green
# Is this an ok "poor man's 2 out of 3" key solution?

(Asked by: username_0 on 2013-01-11)

In the situation that you want no individual to have the complete private key, but you do want to share the complete key between 3 individuals, of which any 2 can construct the complete key, what is the downside from doing something like this:

Orig key = 1 2 3 4 5 6 7 8 9 (abbreviated for demo)

key 1 = 1 2 \_ 4 5 \_ 7 8 \_

key 2 = 1 \_ 3 4 \_ 6 7 \_ 9

key 3 = \_ 2 3 \_ 5 6 \_ 8 9

obviously any 2 keys would construct the entire key again.

Apart from the decrease of key strength to 1/3 of the original, are there any other potential issues ?

This would be used for "short term" escrow accounts where, in the case of a "winner takes all", the escrow would just communicate their key to whichever counterpart won. If the escrow failed to send, then the counterparties could choose another (trusted) escrow and transfer the funds to them.

**Tags:** private-key


---

## 4 answers

### Answer by username_1 on 2013-01-18. Score: 3 | Accepted answer

There are two problems with your approach. The second one's more difficult to solve than the other.

## Problem 1

While it would take me a 100 million years to brute force the key `1 2 3 4 5 6 7 8 9`, if I know two thirds of the key, it doesn't take just 1/3 the time, but a cube root of the time, meaning that I might actually be able to guess it.

### Giving everyone a part of the key without making bruteforce faster

1. Instead, you generate 3 totally random strings of bytes as long as the key. We'll call these R1, R2, and R3.
2. We'll call the private key K, and the clients, C1, C2, and C3.
3. To C1, you give R1, and R2 ^ K. (^ is shorthand for [XOR](http://en.wikipedia.org/wiki/Exclusive_or))
4. To C2: R2, R3 ^ K
5. To C3: R3, R1 ^ K

*Example*: If C1 and C2 put their heads together, they could combine R2 and R2 ^ K. This is important, because R2 ^ R2 ^ K = K  
*Space requirement*: Given that n = number of people, and m = maximum number of people abstain, you need n!/m!/(n-m)! ciphertexts. Okay for 3 people, starts to get unwieldy for 10.

## Problem 2

When generating the key in the first place, somebody needs to know the full private key before they split it up. In other words, you need a trusted third party. To get around this, you need to do something called [Distributed Key Generation](https://en.wikipedia.org/wiki/Distributed_key_generation). I'm not sure if this can be done for ECDSA. [This paper](https://ieeexplore.ieee.org/document/5626958) looks encouraging based on the abstract, but I can't see the whole article.

### Multi-signature transactions

This is a much more scalable and secure system. Unfortunately, it's not really ready for real-world use yet.

> **Comments:**
> **username_0**: Thanks for going into the detail and providing an alternative better method. I'm waiting for multisig but wouldn't mind having something in the intertim and get the rest of the stuff around it done and then just replace with multisig when it hits prime time.  

---

### Answer by username_2 on 2013-01-15. Score: 2

Your proposed solution would now work without a third party knowing the complete key. It is impossible to derive a valid public key from three partial private keys in the way you described.

On the other hand, it is possible to create n-out-of-n multisig addresses using [split-key vanity addresses](https://bitcointalk.org/index.php?topic=90587.0). However, this can have an issue with coins getting lost and one party being malicious and stealing all the coins once they get their hands on all N keys.


---

### Answer by username_3 on 2013-01-14. Score: 2

You should follow username_4's advice and use multisig. There are a few problems with your system. The first problem is how two people share their password. One of them could lie and get the whole password. Even if they share the right values, they need to agree to send a transaction which divides the funds. The user sending the transaction could cheat and send it all to his/her account.

Also, notice the security is much worse. I'm not sure what you mean by 1/3 of the security. If you refer to bits/digits this is right, but this is much less security. In your example, instead of trying all values from 0 to 999999999, any of the participants can guess the password with only 1000 attempts (they just need to fill three gaps). In Bitcoin, instead of a key with around 256 bits, you get about 86 bits of security. This seems decent enough for short times, but is much less secure.

With multisig the users will only sign a transaction they agree with. They know what they get, the key is as strong as in any other transaction and it is easier to scale to more than three users.


---

### Answer by username_4 on 2013-01-12. Score: 1

The way you address this you should use the script CHECKMULTISIGVERIFY with 3 different key provide within one transaction each party having his own key.

See [here](https://en.bitcoin.it/wiki/Contracts#Example_2%3a_Escrow_and_dispute_mediation) for an example that resemble with what you were asking.


---

