in the process of doing stuff to fight traffic analysis, i need to generate a bunch of fake pgp messages. it is possible to asciiarmor random bits, but this is pretty easy to spot. does anyone know a good way to generate a large amount of bogus pgp messages?

What better way than to generate real pgp messages that encrypt noise files? Just generate pseudorandom binary data of pseudorandom length (biased toward the length of real messages), and encrypt with pgp, using the public key of some person's key from a public server, selected at random. If you want to be able to spend less cpu time, you could hack a copy of pgp to simulate doing this, of course, using the symmetric key cipher (idea) in a stream cipher mode. Peace to you. ___________________________________________________________ |\ /| | | | | \/ |o| | Michael Paul Johnson Colorado Catacombs BBS 303-938-9654 | | | | / _ | mpj@csn.org ftp:csn.org//mpj/README.MPJ for crypto stuff | | |||/ /_\ | aka mpj@netcom.com mpjohnson@ieee.org mikej@exabyte.com | | |||\ ( | m.p.johnso@nyx.cs.du.edu CIS 71331,2332 PGP key by finger | | ||| \ \_/ |___________________________________________________________|

in the process of doing stuff to fight traffic analysis, i need to generate a bunch of fake pgp messages. it is possible to asciiarmor random bits, but this is pretty easy to spot.

You'll have to write a simulator for PGP messages. This is straightforward, since the outer part of a PGP doesn't contain much information. There's the destination ID (those naughty bits), an encrypted session key, and an encrypted body. I recommend that the next PGP release come with just such a simulator. Fake messages are a useful primitive for certain tasks and their use should be supported. For similar reasons, a simulator for faking cleartext signatures should also be distributed. The destination ID should be chosen at random from a list of known ID's, maybe with some randomly generated ones added to the list. These shouldn't be flatly distributed because destination ID's are not flatly distributed. Download a big ol' public keyring and use that. [There's a small opening here. If the opponent were to seed the public keyring with keys known not to be in use, they could detect some of the messages as fakes, and certainly the presence of fakery. On the other hand, if _none_ of the messages used known moduli, that would be equally suspect.] The encrypted session key should be less than the RSA modulus for the given destination ID. For arbitrary ones added to your list, make a data structure which contains an upper limit, a substitute for the modulus. The encrypted body is just the output of your favorite PRNG. Since this is a simulation of encrypted text, you don't need the really strong characteristics of a good PRNG. Here's my recommendation. Take a cryptostrong PRNG and generate a seed of sufficient length (like 128 bits). Take this seed and seed a PRNG of lesser quality and (much) greater speed; a linear congruential generator would be fine. For each block of output, take a secure hash, like MD5. [crypto-strong PRNG] [slow seed 128 bits] | v [crypto-weak PRNG] [block 1] --> [block 2] --> [block 3] --> | | | v v v [MD5] [MD5] [MD5] ... | | | v v v [output 1] [output 2] [output 3] If the strong seed is too small, you could simply generate all messages and do an exhaustive search. If the space of the weak generator is too small, that's where to do the search. The reason for the one-way hash is to prevent detection that a random generator is behind it all. Eric