Thanks, cyphergurus

["W. Kinney" <kinney@ucsu.Colorado.EDU>]

Thanks to all for the ideas.

Matthew J Ghio writes in response to my question on Mac encryption:

> Solution: Perform a one-way hash of the data file and use the result of
> the hash to encrypt the header.  Then encrypt the file.  This means that
> the file would have to be decrypted before the header could be decoded. 
> Breaking the code would therefore be more difficult because the file
> format would not be known.

Now THIS I like. There have been a couple of suggestions to use random
numbers in one way or another, but one thing I've been trying to avoid
is having to depend on a PRNG in any way (the same plaintext will always
create the same ciphertext, then, but there seems to be nothing particularly
weak about that -- correct me if I'm wrong). I don't trust the damn
things, and REAL random numbers are just too hard to come by.

As a matter of fact, I'm ALREADY MD5 hashing the plaintext to use as a key
verification block (I posted about this a while ago). The first 4K of the
plaintext is hashed and encrypted with the same key as the plaintext. That
way, when the file is decrypted, it can be hashed again and the new hash
compared to the old hash. If the hashes match, the key is good.

So I guess I'm modifying my request to ask for critiques of this scheme:

Encryption:
(1) Prompt for a pass phrase (I allow 255 characters)
(2) MD5 hash the pass phrase to get an IDEA encryption key
(3) MD5 hash the plaintext to make a key verification block
(4) Encrypt the header info (type, creator, fork lengths) with the
    key verification block.
(5) Encrypt the plaintext and the key verification block with the IDEA key

Decryption:
(1) Get pass phrase as above and hash to an IDEA key
(2) Decrypt the ciphertext with the IDEA key
(3) MD5 hash the new plaintext to make a key test block
(4) Decrypt the key verification block produced in (3) above with the IDEA
    key.
(5) Compare the key test block with the key verification block -- if they
    match, the key is good.
(6) Decrypt the header with the key verification block.

Note that in practice, I'm encrypting the file 4K at a time, and only 
hashing the first 4K block to make the key verification block. The
header info and the key verification block are stored in a RESOURCE.
This is for local, symmetric encryption on a Mac, and there's no point
in not using the tools available. You wanna talk to a DOS machine, use
PGP -- that's what it's for.

> 
> By the way, what encryption algorythm are you using?

IDEA CBC, natch. The application is fully Mac (dialogs, alerts, whatnot),
drag-and-drop, AppleEvent aware. Should be pretty easy to make an Alpha
TCL module to call it.  It does recursive encryption of directories or
entire volumes, properly resolves aliases, and knows enough to keep you
from encrypting your own system file.  I've also got most of the work 
done on a compatible text editor which allows you to edit encrypted files 
without ever decrypting them to disk. All System 7 only. The only glaring
omission in the initial version will be no data compression, but I'd
rather get the thing out and add that later.

Expect aroud a month, maybe two before it's ready for beta. It will be
freeware, and come with source. I plan to post later to discuss establishing
a PGP key for my "software company" pseudonym, for source/executable 
verification.

Comments are solicited -- I'd be willing to modify or add things in response 
to cool flames...


                                 -- Will


(Sorry -- no signature on this one...)