-----BEGIN PGP SIGNED MESSAGE----- There has been some list discussion about defeating traffic analysis of remailers by altering the incoming and outgoing size of the files. But is this not accomplished by merely encrypting with the remailers public key? Assuming it is an encryption supporting remailer that is. When the file size changes as PGP encryption is stripped off it and the files are not sent out in the exact same order as they arrive, would it not be very difficult to ascertain that file of size X enters a remailer and emerges as size X-y. Or can one easily deduce y from PGP's parameters? Even if y is easily deduced this problem can be overcome. I have used various layers of compression utilities and encryption to change message size so that as the first layer of encryption is stripped off, the file is then in a File.zip state. This is then unzipped revealing another encrypted message with an address header. Upon being sent to the next series of remailers this same course of events could then be replicated ad nauseum. Combine this strategy with file stuffers and one would likely have a hell of a time trying to match incoming/outgoing file sizes and where they originated from/are going to. Granted this is a pain, but it would seem that automation could easily be implemented. Scott G. Morham !The First, Vaccinia@uncvx1.oit.unc.edu ! Second PGP Public Keys by Request ! and Third Levels ! of Information Storage and Retrieval !DNA, ! Biological Neural Nets, ! Cyberspace -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLPVDjD2paOMjHHAhAQFclQP7BeTl891Edj2ZgSQvKgtHXPtRAGweu3+h Jee+6vOf8BKvcZMlc78PQ5BF+2YNc70NdTCSG8860X/Rc4oJYiLHLfKRPRP5JlsE ogZiMHxVEvRt+YLDvQTrE3VcvOdb25HUKpcZvNggoR7Ouge1YlH+14Tvf2+oogCD VXbcFVxNi+E= =Yt/P -----END PGP SIGNATURE-----