Cyphergurus: Advice needed
-----BEGIN PGP SIGNED MESSAGE----- I'm writing a Macintosh encryption application (nearing completion), which, when it encrypts a file, changes its file type and creator so that the encryption program will be launch when the file is double-clicked. I have to save four pieces of information about the original plaintext: file type, creator, data fork length, and resource fork length. These are placed in a resource in the encrypted file. What I'd like to get opinions on is _should I encrypt this header information_, since its format will be known to an attacker and, in many cases, its contents easy to guess? My inclination is to leave it plaintext, since the worst that can happen if a file type is known is the same type of attack that would _always_ be possible with an encrypted header. Thanks to all with thoughts on the subject. -- Will -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLN9hEPfv4TpIg2PxAQEZCwP9G2nysBI31CnD2UasTUHQb3itwc2S1juc TGJRvo5iB1WRFHwYwxyraae41Kf2Xsu6qiuHAQWEuvGhG4MyiZjXwZsE5FU9pxRR CV/pvSG4J/teXvJXv575Vr3lVxI6isDa4oZcMtv5rOS7ihIqF4ssuHnlOa6mHckU KW81MGB8nkQ= =cLCE -----END PGP SIGNATURE-----
Will Kinney <kinney@ucsu.Colorado.EDU> asked for advice on the following:
I'm writing a Macintosh encryption application (nearing completion), which, when it encrypts a file, changes its file type and creator so that the encryption program will be launch when the file is double-clicked. I have to save four pieces of information about the original plaintext: file type, creator, data fork length, and resource fork length. These are placed in a resource in the encrypted file.
What I'd like to get opinions on is _should I encrypt this header information_, since its format will be known to an attacker and, in many cases, its contents easy to guess? My inclination is to leave it plaintext, since the worst that can happen if a file type is known is the same type of attack that would _always_ be possible with an encrypted header.
So what you're saying is that you don't want to encrypt the header because it has a known format which would allow a cracker to surmize certain info about the plaintext which would facilitate decryption, but you don't want to leave the header in plaintext because it would convey information about the file format which would facilitate breaking the code. 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. By the way, what encryption algorythm are you using?
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...)
What I'd like to get opinions on is _should I encrypt this header information_, since its format will be known to an attacker and, in many cases, its contents easy to guess? My inclination is to leave it plaintext, since the worst that can happen if a file type is known is the same type of attack that would _always_ be possible with an encrypted header. Thanks to all with thoughts on the subject. -- Will I do think that you should encrypt this information. What if you embed the header at some random point in the file, with the last bytes of the file being a pointer to where the header is? You can then splice the header information out of the decrypted stream. Cryptoexperts: Does this make it harder to use the header information to decrypt the file? What if you embed a series of pointers: ie. Pointer to pointer to pointer to header, all of which get spliced out in the end. Or how about embedding the header in an out of band stream which is part of the file - Escape signals an out of band message and Escape-Escape the old Escape character. Then you could also place the header at a random point in the file. I suppose that you get information about the frequency of the escape character (since the file grows) but that can be masked by appending a random amount of extraneous data in all files). -alan
participants (3)
-
Alan Ruttenberg -
Matthew J Ghio -
W. Kinney