37

Is it safe to split a private key file and put it in different locations? I mean can somebody actually do anything with only a part of a key?

Improve this question
15
  • 4
    Isn't this trivially easy by just deriving two values which when xor'd together produce the key? You could theoretically extend this to any number of values required to be combined to produce the secret. Or am I missing something?
    – Sandy Chapman
    Commented Aug 23, 2017 at 20:49
  • 61
    This looks like an horcrux
    – IAmJulianAcosta
    Commented Aug 23, 2017 at 21:39
  • 2
    @SandyChapman Interesting idea! For each 1 in the key, flip a coin for whether the pieces get 1's or 0's; for each 0 in the key, flip a coin for which piece gets the 1. At first glance, seems ok because a 1 or 0 in the key does not lead to a bias in whether you get a 1 or 0 in the pieces, though I think it's impossible to scale that up to a "k of n pieces need to be present" that all the standard secret sharing algs have.
    – Mike Ounsworth
    Commented Aug 23, 2017 at 21:50
  • 1
    If you mean just spreading data required to get the key across your drive, then the attacker instead of locating the key will have to locate the program, which assembles it, and this will immediately lead to stealing the key. So there's really no point in doing that. However, if you plan to use different measures of security for different parts (one part is in truecrypt vault, another on a sheet of paper in the wallet, etc), then of course it will reduce chances of a breach.
    – Serge Seredenko
    Commented Aug 24, 2017 at 0:34
  • 1
    @L.DUPRÉBERTONI You could do those things, as long as you're not pretending that you're getting any security from them. Seriously, find a tool that does Shamir's Secret Sharing and use that. It shouldn't be too hard to get set up.
    – Mike Ounsworth
    Commented Aug 24, 2017 at 12:23

2 Answers 2

Reset to default
54

Just splitting the file up will not have the desired effect (as A.Hersean explains in their answer).

I think what you're looking for is "Secret Sharing" algorithms, most notably Shamir's Secret Sharing algorithm (thanks @heinrich5991), where the secret is split up into N pieces and given to different people for safe-keeping. To reconstruct the secret, all N pieces (or in some variants, only k of the pieces) need to be brought together. The attacker gains no information unless they have all the pieces.

Although used in many applications, I don't believe it is available in openssl or CAPI. There are many robust open source implementations -- see this question, but you'll need to do some homework to decide if you trust the implementation to not be back-doored.

There is also the related concept of "Multi-party encryption"; where you encrypt the secret with multiple people's public keys, and then all of them need to participate in decrypting it. Here's a SO tread about it:

Encryption and decryption involving 3 parties

You can do a poor-man's version of this using only the RSA implementation you already have by chaining RSA encryption:

RSA(key1, RSA(key2, RSA(key3, secret) ) )

If you want 3 people to encrypt, but only 2 of them need to be present to decrypt, then you can store 3 versions of the ciphertext:

RSA(key1, RSA(key2, secret) )
RSA(key2, RSA(key3, secret) )
RSA(key1, RSA(key3, secret) )
Improve this answer
1
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop ♦
    Commented Aug 24, 2017 at 7:56
39

A private or secret key is not meant to be cut. For example, if someone get hold of half of a symmetric key of 128 bits, the strength of the key would not be divided per 2, but it would be reduced by 18446744073709551616 (= 2⁶⁴). The remaining part of the key could be broken very fast. The same holds for asymmetric key (used by CAs), but the math is more complex.

So do not do it. This will increase the complexity of your solution while reducing its security, because you would have at least two places to secure instead of just one.

Improve this answer
7
  • 30
    "Put all of your eggs in one basket- then WATCH THAT BASKET."
    – J Kimball
    Commented Aug 23, 2017 at 13:49
  • 5
    However, if I generate 128 bits of high-quality randomness, and call it "A", another 128 "B", etc. I can then calculate K xor A xor B xor C = D and give A, B, C, and D to four different people. K can be reconstructed by xoring together the four "parts", none of which is literally a part of the key. Any 1, 2, or 3 "parts" is completely useless.
    – Monty Harder
    Commented Aug 23, 2017 at 21:50
  • @A.Hersean: The link you offer for XOR sharing being flawed simply says that the random parts have to be really random. That same requirement surely applies to the random upper coefficients used in Shamir sharing, so why is one scheme flawed and the other is not?
    – hmakholm left over Monica
    Commented Aug 24, 2017 at 13:37
  • 1
    I misread a comment in the link I provided. What I wanted to say is that If an attacker gets a plaintext, its corresponding encrypted text, and all but one key, the attacker can find the remaining secret key. This is an impracticable attack scenario, but it show that the trivial (XOR) algorithm is weaker than those mentioned in Mike's answer.
    – A. Hersean
    Commented Aug 24, 2017 at 13:46
  • 2
    @Damon For RSA, it depends of the encoding of the key and which part of the key you get. For ECC I cannot answer you, but that would make a good question for crypto.SE.
    – A. Hersean
    Commented Aug 24, 2017 at 14:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .