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...)