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