🚀 go-pugleaf

In article <R90TwB1w165w@west.darkside.com> sspy@west.darkside.com (mshannon) writes:
>Another question, gentlemen. Suppose someone, the feds or whoever, hace 
>an encrypted disk that they want to crack, but they don't know what 
>cipher was used. How can they find out. Are there programs that will 
>analyze it and make this determination based on the way certain ciphers 
>cipher?

In general, no. By itself, any good cipher produces ciphertext that is
indistinguishable from purely random bits by anyone who doesn't know
the key.  In practice, however, many encryption packages format their
ciphertext output to make it easy for the intended recipient to
recognize as a message encrypted with that particular package. This
will tip off an eavesdropper that a particular system and possibly a
particular set of keys are in use (implying the identities of the
correspondents), even if he can't actually crack the contents.

For example, PGP puts out the "BEGIN PGP MESSAGE" banner, and it
specifies the public key that was used to encrypt the message so the
receiving program knows which of possibly several secret keys to use
to decrypt it. Anyone with a reasonably complete public key collection
can see who an intercepted message is addressed to, at least at the
outermost level (it might contain several levels of encapsulated
encryption, as in some of the anonymous remailer schemes).

Other encryption packages, such as Sun's 'des' command (and the one I
wrote that's compatible with it) produce *no* identifying information
in the ciphertext -- it looks like purely random bits. This has the
advantage of denying an eavesdropper knowledge of the system you're
using, but it has the disadvantage that the user must know, a priori,
which algorithm and key to use to decrypt it. This is okay in a single
key cryptosystem (you could consider the algorithm specifier to be
part of the "key" that you exchange ahead of time) but it is not
practical in a public key cryptosystem, which is supposed to let you
send encrypted messages to someone without special prior arrangement.

On the other hand, it would not be hard to take that little bogus PGP
ciphertext generator I posted the other week and go much farther with
it. It could produce a properly formatted PGP message, with correct
checksums, etc, that causes PGP on the receiving end to prompt for a
totally random and fictictious key. To an eavesdropper, such messages
would be indistinguishable from real PGP messages encrypted with
unknown public keys. One could conceive of generating continuous
streams of such traffic just to provide some haystacks in which to
hide your needles.

Phil