Re: [Hampshire] Bash pipe creates infinite loop - why?

Richard Brown wrote:
> On Fri, Apr 4, 2008 at 12:12 PM, Russell Gadd
> <russ.mail.lists@???> wrote:
>> I am at a loss to understand how you can passphrase the key without
>> having the key in the first place - chicken and egg problem, unless you
>> use a different method of encrypting the key?
>
> What you seem to be proposing is that you bcrpyt a file using a key,
> give the key to someone else, and that they can use the key and a
> readme file to decrypt the file in the event of your untimely demise.
>

I maybe should have used the term passphrase rather than key. As the
man page says "regardless of the passphrase size, the key is hashed
internally to 448 bits" then the passphrase is wiped from memory. The
readme file would tell them what software and procedure to use.

> What Bob is saying is:
>
> You could create a pgp keypair, put your secret key on the disc with
> the readme, and then instead of telling the third party the "key", you
> tell them the passphrase to unlock your secret key. As Bbob said, the
> disk would only be as secure as your passphrase in that instance.
>

This seems like the same effect as my proposal - only as strong as the
passphrase, since someone could brute force it if they really wanted to,
so it needs to be a reasonably good passphrase. The main requirement is
to avoid problems if the CD gets lost.

Having read the gpg stuff again I now see where my problem was. I
assumed you needed to use one of the key pairs to encrypt the stored
key, whereas presumably there is an algorithm in the gpg system which
encrypts the key just using the passphrase.

The problem I have with that solution is it is my understanding that
this forces the third party to use gpg, which is not a simple matter for
someone to set up if they are not used to it particularly non-*nix users
(maybe I'm wrong here - unfortunately I'm not able to come to the
meeting on Saturday or I could have educated myself a bit on this
stuff). My readme file would say something like "for Windows copy these
files into a new folder on your hard drive and click this one - or use
"Run" and type this on the command line. For Linux type this command in
a terminal (on my PC??) ..."

> If you're going with an envelope a the solicitor's there's no reason
> you can't encrypt your data on one disk with pgp and give the
> solicitor the secret key on another disc and passphrase at the same
> time. Although I'm not sure I'd trust a cd with that sort of stuff.
>

Yes I wouldn't put the passphrase anywhere near the keys. The
solicitor/family executor gets the passphrase now but doesn't get the CD
normally until such time as I snuff it and he/she is given the latest CD
by my relatives (or possibly the whole PC? in which case they could get
the account codes except they may be encrypted with other passphrases
they don't know). The contents of the CD keep changing.

I wonder if anyone else has thought through how their encrypted personal
stuff would be recovered in the event of their demise? Maybe they are
relying on the bank to reveal all given sufficient evidence. But which
bank(s), insurance companies, investment companies, which accounts, what
other information is required? Is it stored on paper somewhere? When you
rely on the computer to store your information rather than filing
cabinets this becomes an issue. Or maybe folks don't bother to encypt
the stuff - ah surely not - Inland Revenue comes to mind :)

The CD idea was actually conceived as just as my personal offsite
backup. I've used a Windows version for some years now. If I lost my PC
in a fire, this is the data I would really need to have - not just
personal stuff but also system documentation, etc. Without it setting
things up again would take much longer. (Maybe I might at some time send
it down the wire to the Amazon S3 service or similar.) It all fits quite
nicely on a CD and the storage reliability time of these is reasonably
good - at least a few years and I only need really a few months at most.
The thing about an executor is something I thought of later but it seems
to be a reasonable practical additional benefit of using on offsite
backup CD, given the extra effort of adding a help file and a couple of
scripts.

Russell