4 expanded posts ยท every known parent and child
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? e
> 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 |
| ||| \ \_/ |___________________________________________________________|RCA's multicast source has a small library of sound files for you to pick from too... Aloha ka ko! -Jim -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.4 mQBNAi2Ig+EAAAECALImsR18LE9I6NKICf8TVhbV6yJgF95ynGHnWnNo1ERfdqzk Zl3Icl2N5klNM3KQ9zM3uN/z55smi2QOiD3hL80ABRO0L0phbWVzIEQuIFdpbHNv biA8amR3aWxzb25AZ29sZC5jaGVtLmhhd2FpaS5lZHU+ =JTj1 -----END PGP PUBLIC KEY BLOCK----- ................................ . == = = James D. Wilson. . " " " P. O. Box 15432............................. . " " /\ " Honolulu, HI 96830-5432......Fr. Excelsior........ . \" "/ \" jdwilson@gold.chem.hawaii.edu.FRC/FAM/AASR/GWB/OTO. ................................................................... On Thu, 14 Apr 1994, Michael Paul Johnson wrote: > > 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