Re: Remailer encryption module

[eric@remailer.net (Eric Hughes)]

   From: Derek Atkins <warlord@MIT.EDU>

   > I agree.  PGP just does not have the support for the encryption
   > required for mixing remailers.

   How
   is PGP deficient?  What do you need PGP to do in order to get it to
   work right with remailers?

Note that I said mixing remailers, not just regular remailers.

-- No support for random padding to a fixed length.  Yes, this can be
patched by script.  Hell, you could rewrite PGP with a script, so the
existence of a workaround is no defense.

-- Message size blowup for encrypted armor-within-armor.  Yes, I know
it compresses, but it would be a better thing to get PGP to unpack a
PGP encrypted message (the message to the next hop) to multipart form,
part regular text, part armored.

-- Inability to restrict PGP from accepting a non-encrypted message.
PGP run on an armored plaintext file will work just as if it were
encrypted.  This precludes being able to require encryption as a site
policy.  (Again this can probably be worked around; again, not an
excuse.)

In addition, there's a few really bad misfeatures for pseudonymity
(which is what everyone seems to want to do with remailers):

-- Identities for secret keys are in cleartext in the secret key ring.
Upon seizure of a secret key ring, presence of a pseudonym name can be
considered a presumption of possession of a corresponding secret key,
simply because people don't fill up their secret key rings with bogus
keys with other people's names.

-- Key ID of the recipient is always in the clear.

-- The RSA-encrypted session key does not have a flat representation
over its multiword container.  This yields a statistical traffic
analysis hole.  (This point is irrelevant without fixing 4.)  Hal and
I completely solved this problem last year.


This is all I can think of off the top of my head.  Not having
analyzed the problem recently, I can't say that I've got everything.

Eric