Scott Morham asks about how well file sizes are preserved by encrypted remailers. Generally speaking, in creating a nested encrypted remailing request, at each stage PGP will attempt to compress the input, then encrypt it, which preserves its size but adds a block to the beginning of about the size of the public key (typically 100-150 bytes), then makes it ASCII, which increases the size by 1/3, then adds a small header block of 50 to 150 bytes or so. Since the compression is ASCII-encoded encrypted text, the best it can do is to "undo" the ASCII encoding or compress by about 1/4, but I don't know if it actually does that well. Probably it compresses by somewhat less. So generally each chain will add a few hundred bytes and scale the size of the message up by probably 10 or 20 percent. I think that this will probably allow pretty reliable matching of incoming and outgoing messages on the basis of size alone, at least, more reliable than I would be willing to count on to prevent attacks by this means. Scott also suggests using .zip compression at some point, but this isn't likely to help much since encrypted files look random and are basically not compressible. What we have talked about here is adding random padding to change the file size. Because encrypted files do look random, you can generally pad them with random bytes pretty easily and undetectably. This depends somewhat on the file format but it is basically easy. I wrote some perl scripts to pad .pgp public-key-encrypted files undetectably. The extra bytes are ignored when the file is decrypted. The scripts aren't really production- quality since they just use perl's built-in random numbers. Good random numbers should be used. Hal hfinney@shell.portal.com