[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Traffic analysis and file size
-----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,
[email protected] ! 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-----