Re: fast des

[smb@research.att.com]

	 > Run your plaintext through compress first; remove the compress
	 > header; then encrypt. Compression will screw up character frequencie
	s
	 > (and use all eight bits) enough to make automated detection of a
	 > successfully-broken encryption really darn hard. Especially if you
	 > keep changing compression technology each message.

	 Most encryption scheams use cypher block chaining or some other
	 mechanism where a change in one block will affect every block to
	 come after it, no?

	 Given this, would inserting a block of random data at the begining
	 of the datastream help?


Probably not.  The DES-crackers are already going to be looking at a
couple of blocks, because in general, the cryptanalyst won't know the IV.
But not knowing it only affects your ability to decrypt the very next block;
you can still get the one after it.

The decrypt equation for CBC mode is

	P[n] <- D(C[n]) xor C[n-1]

That is, without knowing the IV -- C[0] -- you can't recover P[1].
But P[2] depends only on C[2] and C[1].  If P[1] is random garbage,
you've actually made life a bit easier -- the block they can't recover
isn't important.