From: Nathan Zook <nzook@bga.com>
To: cypherpunks@toad.com
Message Hash: 899fff160015891223da3bcf5fea4e9526634ca46ecd55789f50f1d71fbbf2ed
Message ID: <Pine.3.89.9501281651.A2705-0100000@edwin.bga.com>
Reply To: N/A
UTC Datetime: 1995-01-28 22:53:34 UTC
Raw Date: Sat, 28 Jan 95 14:53:34 PST
From: Nathan Zook <nzook@bga.com>
Date: Sat, 28 Jan 95 14:53:34 PST
To: cypherpunks@toad.com
Subject: Why encrypt intra-remailernet.
Message-ID: <Pine.3.89.9501281651.A2705-0100000@edwin.bga.com>
MIME-Version: 1.0
Content-Type: text/plain
-----BEGIN PGP SIGNED MESSAGE-----
Suppose Alice sends Bob a message e(M) through Chaum. Eve, a stong
opponent, wants to trace the message. She keeps track of all outgoing mail
from Alice, an MD5 hash of all incoming messages to Bob, and outgoing from
Bob. Eve then sends Chaum e(M), and waits for a matching MD5 to Bob that
doesn't correlate to an outgoing MD5 from Bob. (Eve knows that Bob is a
remailer.)
(Thanks to whoever came up with Eve. I'm embarassed that I didn't think of
that trick.)
Clearly, this generalizes.
Gentlemen, I believe that I have just stumbled upon a strong proof of
the necessity of remailer auto-encryption of all messages. Since the
session key is PRG, MD5 will change (a lot;). Furthermore, remailer auto-
encryption allows the mailers to number their messages to each other. A
low number means a re-transmit from the remailer, which is not possible,
unless some sort of ACK system is in place, and even then, would still
flag. Of course, if the remailers _sign_ their messages (on the way out)
as well, you could compare the timestamps of the signatures with the
message itself.
- ---
I also believe that the spammed remailer attack reveals another
important weakness: if 50% of all mail leaving Alice during one tick goes
to Bob, then Eve can gain probablistic information about the messages that
Alice recieved, when attempting to trace a message through the net. This
"attack" suggests a rational use of garbage:
1) A remailer always sends at least as many messages as it recieves,
_including junk_.
This means that you don't have a system "mysteriously" recieving
200 messages, and sending eight.
2) A remailer always sends at least n messages per tick. (n may vary
between remailers.)
If a remailer has very low traffic, that traffic is still
protected.
3) On a given tick, a remailer always sends the same number of messages
to each other remailer.
This eliminates the effectiveness of a spam hit on a remailer of
an old message.
4) Designated users of the net receive the same number of messages from
each remailer each tick. (Such users probably _send_ the same
number of messages each tick, as well. Note also that if some
remailer is untrusted, that will be reflected by its always being
sent garbage.)
This puts the users "inside" the net.
No, these axioms do not blow up the amount of garbage. New messages to
the net displace garbage, unless they raise the maximum for the number
going to a particular remailer.
This system also has the advantage of _immediately_ fully integrating
any new remailers. New remailers don't have to build up their users in
order to be secure.
- ---
By combining these two, I believe we can turn the remailer net into a
black box, including designated users. A communication should be safe if
either end is in the black box. I believe that "PGP only" is the only way
that remailers will be able to fulfill their potential. It should also
increase the base of PGP users.
- ---
I nominate the phrases "Execute plan X.", "I have the soveineers.",
"Your fried chicken is ready.", and "The NSA is a bunch of idiots." for
garbage. If they ever attempt to prosecute, the have to reveal that they
broke IDEA or RSA to X digits.
___
Note that the maintainence of an MD5 log of all messages by recipient
by the remailers can be used to kill primitive spam/bombs.
"PGP?" "ITAR!" "Oh, RKBA!"
|--------------------------------------------------+
----------------- 14712B4D 1994/12/26 Nathan H. Zook <nzook@bga.com> )
|44B3D866 3D551E2E ---------------------------------------------------
|F89222A6 338CDE24/ |
-----------------
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQEVAwUBLyrUVnmgMs8UcStNAQH18wf/a4SSoew9TJeaLsGWg+rL6wqm2RStrdFI
XOULDD7e1yaYLBaovSz8BeNgHgW1UUAiKWWsl4rmVQ+QI1u2Oprgzo/mGy5qa1Bv
i2GK9yjRleypn06fOf9kS7lr8ACO71m+1L/HPz+NBlPCgg6hCaWSJfoJkSQ1cHYi
5SHCvn/s/zLypgxcbDNqDF3eBMgpYokhFFyoTeD8LfNEtqQB/EGOwMlsik9YaKGg
5djDfDBucRsWy1a7H9G/BPejacA7PsIBKIIjbsQbxqCIczjzPR75j69ypM1IAtow
kCwq6KH4d9dyKPaB5Q564LsDiEkrift+84/rADro6L5ppi4GG4PFmQ==
=NgpM
-----END PGP SIGNATURE-----
Return to January 1995
Return to “Nathan Zook <nzook@bga.com>”