Key safety vs Backup : History of a bad day (key-restoration problem)

[Roscoe]

Hmm, maybe I lost my meaning in trying to avoid verbosity.


If I decided my mum, dad and brother could be trusted, I'd encrypt my
private key with a strong password.

Then I'd use ssss to generate 3 shares, which when combined would
reveal the password to the private key.

Now I'd distribute to my mum, dad and brother a copy of my private key
and a password share each.

Now lets say my private key ended up being 200 characters and my
password 20 characters.

To reconstruct it I would have to type in 200 characters once, and
around 60 characters to recover the password (from the three shares)

Constrast that to if I applied secret sharing to the unencrypted
private key, I would, in order to recover my private key have to type
in around 600 characters (from the three shares).


ssss is open source and written in C,  I don't see how there is any
case for longer-term storage by avoiding ssss and using just paperkey.
(If C compilers disappear paperkey and gpg aren't going to be very
usable either)

To include secret sharing in paperkey would indeed result in fewer
components and fewer steps because you're inserting the functionality
like that of ssss into paperkey and thus making paperkey more complex.
I suppose thats a preference thing, as I mentioned I like the one tool
one job philosophy.

Now in light of having to type in more data (and thus one must store
more data reliably) and replicating functionality already provided by
ssss/paperkey I'm not seeing any advantage.


But! It is clear, there is a demand for secret sharing in paperkey :)


[I've made the assumption that the shares are the same size as the
secret, this  makes sense to me as you're encoding things as points in
N space but I don

On 11/1/07, Robert J. Hansen <rjh at sixdemonbag.org> wrote:
> On Fri, 2007-11-02 at 14:20 +0930, Roscoe wrote:
> > I don't see any worthwhile gain over setting a strong passphrase, and
> > then secret sharing that passphrase with ssss.
>
> Fewer things can go wrong.
>
> Secret shared passphrase + private key: what happens if the private key
> is unavailable?  E.g., I die when my house burns down and my computer
> cooks and even my back-ups are toast.  With a SS passphrase, I have to
> make off-site backups of my private key... and then I have to make sure
> that those off-site backups are still readable, since CD-Rs tend to go
> bad... and if I replace one, I have to make sure the passphrase is the
> same as the secret-shared passphrase...
>
> Secret shared paperkey: the private key is available as long as the
> secret shares are available.  OCR the SS paperkey, recover the private
> key, boom, you're off to the races.
>
> Fewer components, fewer steps, fewer dependencies, longer-term storage:
> it's an all-around win.
>
> > The biggest practical difference is that since you're secret sharing
> > just a passphrase and not a secret key it's going to be less typing to
> > reconstruct your key.
>
> 147 bytes is not an onerous reconstruction job, even if you have to do
> it by hand.  Base64 it and it's about 200 characters, or two and a half
> lines of text.
>
>
>