Bob Dunlop wrote:
> Hi,
>
> On Thu, Apr 03 at 08:53, Russell Gadd wrote:
> ...
>> Thanks Bob. I'd use a different encryption program if I could find a
>> suitable one. I want something which will record encrypted files on a CD in
>> a way which allows a different user with the passphrase (and an unencrypted
>> help file on the CD) using either Linux or Windows to read it (e.g. an
>> executor of my estate). I don't want to use keypairs as this seems to tie
>> the data to me/my PC, so this rules out gpg. Any suggestions would be
>> welcome.
>
> I'm not sure that Bash combined with bcrypt is going to be that portable ?
> Is there a Windows implementation of Bash ? Also bcrypt only lists Win32
> and seems to have had portability problems with 64 bit systems in the past
> so I don't now how future proof it's Windows implementation is.
>
Yes I tested the Win32 version and with a command line batch program it
works fine. Not sure about 64 bit, maybe it could be a limitation.
> Personally I'd encrypt my data with the target users PGP key, or if they
> don't have one create one and put the private key, passphrase protected
> of course on the same disk. Your protection would only be as good as the
> passphrase protection in this case.
>
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?
Basically I'm thinking of setting up something where someone with a
reasonable amount of intelligence and at least some knowledge of Windows
can read the unencrypted help file and use other simple programs on the
CD (a Windows batch file, Win32 copy of bcrypt, a bash script for the
more Linux initiated types) to recover the data. They'd need the
passphrase given to them by another means - this would be your trusty
sealed envelope deposited with solictor.
> As for you intended use I'm not sure that I'd trust electronic media to be
> stable for significant lengths of time. Floppys, my stable storage from
> only 20 years are are now virtually unsupported, DAT tapes from a decade
> ago the same, and CDs only last a few years. HD DVD wouldn't have been a
> good choice either :-)
>
I see you are younger than me :)
Long term storage is not a problem. I will be recording CD's regularly.
I just won't know which one is the last one which they will need to
recover from.
> For legal documents and long term storage I use plain text ink on paper
> in a sealed envelope in a fire proof box with a copy lodged with my
> solicitor. Hard to beat some old methods.
>
>
>> Thanks for the info. Minor question: I read bcrypt's documentation (man
>> page and web site) but I don't think it said anything about return codes.
>> Maybe there's some other way of discovering this?
>
> My discovery method was the Star Wars method. Use the source Luke :-)
>
> Source code is often the quickest way to get the definitive answer
> especially when documentation is incomplete.
Excellent suggestion, which I hadn't really considered. I looked at the
source code and it appears less daunting than I expected. I dug out my
old yellowed copy of K&R and grepped for exit and return. You must have
done a bit of digging for me - many thanks.
Maybe I'll get the old grey cells churning a bit and if I can
successfully compile the source I'll try tinkering with it to remove the
infinite loop - probably just exit if it fails once (but after asking
for the verifying string) :
fprintf(stderr, "Encryption key:");
fgets(key, MAXKEYBYTES + 1, stdin);
/* blowfish requires 32 bits, I want 64. deal w/ it */
while (strlen(key) < 9 && type == ENCRYPT) { /* \n is still tacked on */
fprintf(stderr, "Key must be at least 8 characters\n");
memset(key, 0, MAXKEYBYTES + 2);
fprintf(stderr, "Encryption key:");
fgets(key, MAXKEYBYTES + 1, stdin);
}
Russell
