2

I have been thinking about a way of storing a "digital testament" without using a physical safe, which is the typical solution I have read. Here is my idea roughly:

  • Generate a strong key pair using GPG/some other standard tool.
  • Encrypt the sensitive information using the previous key.
  • Store the public key with enough redundancy.
  • Split the private key using a secret sharing tool. Let's say 3 shares, 2 to recover the secret.
  • Make my 3 witnesses keep a written-down copy of their shares, plus the encrypted payload.

In this way I can update the payload (if more sensitive information needs to be stored later) without updating the shares.

I'm barely a crypto/security aficionado, and I know that complexity is the enemy of security, and that devising your own security schemes is asking for trouble.

What are the flaws of this method?

user72036
  • 21
  • 1
  • If you like to update your sensitive information I guess you need the unencrypted data. So where do you store your copy of the private key? – Jonas Wolf Apr 08 '15 at 18:15
  • Let's say the sensitive information is just a (short) collection of passwords. I just need the public key to encrypt versions 2, 3, etc. – user72036 Apr 08 '15 at 18:59

1 Answers1

1

To the best of my knowledge this is secure, if you choose all primitives correctly.

If I'd want to use such a system (and I have thought about it already), I'd go with a similar approach.

However I'm suggesting you one change:

Don't give your witnesses the payload.
Give them the shares, so they can reconstruct the private key and let them then get to your location (your house maybe? a internet-download-server maybe?) and let them reconstruct the key there. Then you'd be able to alter the payload (if neccessary) even after having distributed the shares.

The beautiful thing about your idea is that you don't need a copy of the private key for yourself, you can simply encrypt the payload using the public key.

Now some (standard) notes concerning the primitives:

  1. Make sure you use a very long key. My plan was to use a 655536 bit RSA key which should offer decent security for the next two centuries.

The next three points apply if you want to protect data for 50+ years.

  1. Make sure the symmetric crypto, you use to protect your payload is decent. (long key size, multiple algorithm structures, multi-encryption. 128-bit isn't enough, you want 512-bit or more + different cipher designs -> Feistel, SPN, ARX, ...)
  2. Make sure the authentication you use is good. (secret key authentication suffices, but again with different structures and long keysizes -> Sponge, sth. like Skein , sth. like SHA-512,...)
  3. Make sure to either update your PBKDF params regularly (once every year maybe?) or to use very aggressive parameters (something that takes hours/days to be computed today).
SEJPM
  • 9,770
  • 6
  • 39
  • 69