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 <[EMAIL PROTECTED]> 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. > > > _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
