Is this an ok "poor man's 2 out of 3" key solution?

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.

private-key

Richard Green

Posted 2013-01-11T13:11:19.313

Reputation: 233

Answers

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

Instead, you generate 3 totally random strings of bytes as long as the key. We'll call these R1, R2, and R3.
We'll call the private key K, and the clients, C1, C2, and C3.
To C1, you give R1, and R2 ^ K. (^ is shorthand for XOR)
To C2: R2, R3 ^ K
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. I'm not sure if this can be done for ECDSA. This paper 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.

Nick ODell

Posted 2013-01-11T13:11:19.313

Reputation: 26 536

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 – 2013-01-19T21:08:00.020

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.

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.

halftimepad

Posted 2013-01-11T13:11:19.313

Reputation: 1 218

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

ThePiachu

Posted 2013-01-11T13:11:19.313

Reputation: 41 594

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 for an example that resemble with what you were asking.

Gopoi

Posted 2013-01-11T13:11:19.313

Reputation: 889