Attacks on remailers

>>>>> On Wed, 25 Aug 93 11:39:11 EDT, J_G_Thomas%CAASD1@mwmgate1.mitre.org said:

	Joe> A new protocol is probably the cleanest way to solve the
	Joe> problem of traffic analysis of messages addressed with
	Joe> encrypted address blocks.  The best way to get security
	Joe> in a remailer chain is to nest your encryption, so only
	Joe> one layer gets peeled off in each remailer hop.  That
	Joe> isn't possible with encrypted address blocks, since the
	Joe> sender will only know the address (and public key) of the
	Joe> first remailer in the chain.  All hops after the first
	Joe> one must send the same message out as they got in, with
	Joe> just a layer off the encrypted address block.

As I indicated in my long posting, it is not necessary to send out the
same message that was received.  Chaum proposed encrypting the message
(the non-address-block portion) with a secret key at each stage, a key
which would be revealed to the remailer (along with the address of the
next address in the chain) when it peeled off its own layer of encryption.

		But if
	Joe> remailers talked to each other by first doing RSA-signed
	Joe> Diffie- Hellman key exchange, then encrypting the
	Joe> traffic, a packet snooper wouldn't be able to correlate
	Joe> incoming and outgoing messages.

If no encryption is done on the message body, there is another attack for
this case that I didn't mention.  It is:

Run a remailer.  For every anonymous address floating around on the net,
try sending a message to it.  Look at the messages which pass through
your own remailer and look for matches to the message you sent.  Any
anonymous address which includes your remailer as one of the elements
will pass through you.  You have then defeated all of the stages of the
chain before yourself.  In particular, if you happen to be the last remailer
of the chain, you have broken the anonymity of the anonymous address.

This attack, while not the most powerful on the list, defeats many of the
principles of remailer chains, such as that the chain is as strong as
its strongest link.  It requires you to strongly trust at least one
remailer in the chain (the last one), whereas without this attack you
would not have to especially trust any single remailer.  So it is sig-
nificant.

Diffie-Hellman encrypting messages between remailers would not help against
this attack.

Also, rather than DH it would be just as effective to use the public key
of the next remailer in the chain, and more convenient: some remailers are
not able to participate in TCP exchanges, being connected to the net
by occasional uucp connections.

This lack-of-TCP problem also impacts the proposal to use a public telnet
port for message communication.  Another problem with that proposal is
that it would need the remailers to run as background processes.  With the
current software they can run as mail filters, which makes them much
less conspicuous to system managers.

The suggestion for remailers to send messages by telnet connection to
port 25 of some other machine (rather than by piping to sendmail as they
currently do) is perhaps reasonable (for those systems with TCP access),
although it makes the remailer somewhat harder to set up since you have to
find some other machine which will let you connect to their port.  Also,
I think some machines may log incoming or outgoing telnet connections to
this port, since it is a common technique for mail forgeries.  I have heard
that most systems will actually not allow public telnet connections to
this port.

I don't know that much about how widely available telnet and other TCP/IP
services are on the net, so if these techniques are more usable than I
am suggesting I'd like to hear about it.

Hal Finney
hfinney@shell.portal.com

>>>>> On Thu, 26 Aug 93 22:11:20 PDT, hfinney@shell.portal.com said:

>>>>> On Wed, 25 Aug 93 11:39:11 EDT, J_G_Thomas%CAASD1@mwmgate1.mitre.org said:
	[...]

	hfinney> As I indicated in my long posting, it is not
	hfinney> necessary to send out the same message that was
	hfinney> received.  Chaum proposed encrypting the message (the
	hfinney> non-address-block portion) with a secret key at each
	hfinney> stage, a key which would be revealed to the remailer
	hfinney> (along with the address of the next address in the
	hfinney> chain) when it peeled off its own layer of
	hfinney> encryption.

	[...]

	hfinney> If no encryption is done on the message body, there
	hfinney> is another attack for this case that I didn't
	hfinney> mention.  It is:

	hfinney> Run a remailer.  For every anonymous address floating
	hfinney> around on the net, try sending a message to it.  Look
	hfinney> at the messages which pass through your own remailer
	hfinney> and look for matches to the message you sent.  Any
	hfinney> anonymous address which includes your remailer as one
	hfinney> of the elements will pass through you.  You have then
	hfinney> defeated all of the stages of the chain before
	hfinney> yourself.  In particular, if you happen to be the
	hfinney> last remailer of the chain, you have broken the
	hfinney> anonymity of the anonymous address.

	hfinney> This attack, while not the most powerful on the list,
	hfinney> defeats many of the principles of remailer chains,
	hfinney> such as that the chain is as strong as its strongest
	hfinney> link.  It requires you to strongly trust at least one
	hfinney> remailer in the chain (the last one), whereas without
	hfinney> this attack you would not have to especially trust
	hfinney> any single remailer.  So it is significant.

Correct me if I'm wrong, but as I see it, there are two goals
for the remailers:

(1) 	Anonymous addresses to which mail can be sent, but the recipient
	is unknown and cannot be determined (receiving anonymous mail).

(2)	The ability to send mail to someone without anyone (including
	the recipient) determing that you did so (sending anonymous mail).


Number 2 can be mostly taken care of with nested encryption of mail headers.

Using the method you mentioned above of including a key to encrypt the
body of the message nested inside each level of nested encryption
would take care of the above problem (having to completely trust the
last remailer) and restore the "chain is as strong as its strongest
link" principle.

This would complicate slightly complicate the final decryption for the
anonymous recipient (having to decrypt the body of the message with each
key in turn.) New software tools could need to be written for
the recipients as well as the sender to handle this easier.

A "anonymous address block" similar to the pgp signature blocks
would be helpful for automating the sending of mail to anonymous
addresses.

To construct an anonymous address block might be something like:

	Anonymous Anne wants an anonymous address.
	First she generates a set of N keys (IDEA, DES or RSA, doesn't
	matter except RSA would disallow a remailer to decrypt what it 
	encrypted using it.) She would then choose a path through
	the remailers and encrypt her address (and perhaps one of 
	the random keys) with the last remailer's key.

	The result of this she would pair with the address of the 
	next remailer closer to her (in the remailing path) and
	one of the random keys, and encrypt this with the 
	next-to-the-last remailer's key
		.
		. (for all hops)
		.
		|
		v
	She would then encrypt the result of the previous operation
	with the key of the intended first remailer in the chain.

	Then she would add the address of the first remailer
	(in cleartext).

	This (largish nested encrypted address chain + cleartext
	first remailer address) she would encrypt (or sign) with the
	secret key of her anonymous persona.

The appropriate software tools would allow someone to reply
to an anonymous address using this "anonymous address block".

	[...]
	hfinney> This lack-of-TCP problem also impacts the proposal to
	hfinney> use a public telnet port for message communication.
	hfinney> Another problem with that proposal is that it would
	hfinney> need the remailers to run as background processes.
	hfinney> With the current software they can run as mail
	hfinney> filters, which makes them much less conspicuous to
	hfinney> system managers.

True, but it would also protect against attack 2 in your "Attacks on
remailers" post -- the mail log problem.

I think it would be fairly simple to include in the next-remailer-address
whether or not to use normal mail channels (for uucp remailers)
or to use socket nnnn connection to the remailer (for the ones
that are capable.)

	hfinney> The suggestion for remailers to send messages by
	hfinney> telnet connection to port 25 of some other machine
	hfinney> (rather than by piping to sendmail as they currently
	hfinney> do) is perhaps reasonable (for those systems with TCP
	hfinney> access), although it makes the remailer somewhat
	hfinney> harder to set up since you have to find some other
	hfinney> machine which will let you connect to their port.
	hfinney> Also, I think some machines may log incoming or
	hfinney> outgoing telnet connections to this port, since it is
	hfinney> a common technique for mail forgeries.  I have heard
	hfinney> that most systems will actually not allow public
	hfinney> telnet connections to this port.

The socket connections to other remailers would use a special port
number. For the last connection (to the recipient) could be either
by socket 25 connection or normal mail, whichever works (preferrably
socket 25.)

	hfinney> I don't know that much about how widely available
	hfinney> telnet and other TCP/IP services are on the net, so
	hfinney> if these techniques are more usable than I am
	hfinney> suggesting I'd like to hear about it.

I haven't seen a machine that doesn't allow just anyone to
connect to port 25. (is there some new authentication protocol
for this that I missed?)


So the attacks and defenses as outlined by hal (with some additions):

(1) Reading the "request-remailing-to" lines in the message to determine
where it is going.

Defeats remailer goal #2.

Defense: can be defeated by nesting the remailer encryption.

(2) Reading mail logs to plot the path of a message.

Defeats remailer goals 1 and 2.

Defense: bypass mail systems on remailer hosts, using special
port socket connection communication wherever possible; run remailers
only on systems that do not keep mail logs.

(3) Monitor messages in real time flowing in and out of remailers,
	correlating the input messages with output.

This is a variation of attack 2, and can defeat both remailer goals.

Defense: Batch remailing messages in a manner which frustrates analysis;
	send fake messages to other remailers in such a manner as
	to maintain a constant flow, removing flow rate cues.

(4) Read header info and check message size for remailer input/output
	correlation cues.

Variation of attack 2, and can defeat both remailer goals.

Defense: Do not preserve any header information; pad messages to remove size
	cues.

(5) Inject a clone of a message into the remailer stream, and look for
	two identical messages to come out of a remailer to track the
	message.

Another variation of attack 2.

Defense: Check for duplicate messages in the remailer and remove all
	but one copy of each duplicate.

(6) Insert duplicate messages in the input stream in seperate batches,
	checking the outgoing batches for copies to track the message.

Same problem as (5) really.

Defense: Timestamp the messages so they are only good for a number of days,
	thus reducing the number of messages to check against for duplicates.

I don't like this defense.
Who would make the timestamp?
Where would you put the timestamp?
How would you prevent spoofing?

	If you added an element of randomness to the procedure that
padded/altered the message before sending on to the next remailer, it
would defend against this line of attack -- so two identical messages
going into a remailer would come out differently. This is where DH key
exchange could be fruitful (with random session keys for each
message.)  (Assuming that the remailers don't know each other's RSA
keys. If they did, then they could simply encrypt a random session key
with the other's key and encrypt the message with the key also, and
ship them both over to the next remailer.)


(7): Look at all messages coming out of the first remailer, and
follow them into their 2nd remailers; take all messages from those and
follow them on, and so on.  This will eventually lead to a number of
destinations, one of which must have been the destination of the original
message.  Over a period of time, look for correlations between destinations
and sources.

Defense: Use large remailer chains of popular remailers.  With enough
mixing at each stage of the chain, the number of possible destinations
will become astronomically large, making correlations statistically
impossible; use of dummy messages to pad flow rate to constant
would increase the difficulty of such an attack (would hide the signal
deeper in the noise.); such an attack (PROLONGED monitoring of all
remailers) would be very difficult to perform, esp. with use of
remailer-remailer socket connections.

(8): Correlate messages being sent from person A with messages being
received a certain time later by person B.  Even without the ability to
track messages through the remailers this can show a communication pattern.

Defense: Send dummy messages at regular intervals, which bounce through
the remailer network and then die.  When you have a real message to send,
replace one of the dummies with this.  The sender's traffic pattern is
then constant and no information can be gained from it.

(9): Bribe or coerce one or more remailer operators into revealing
their keys, or into decrypting the desired messages.  Alternatively, run
many remailers, pretending to be dedicated to privacy, while secretly
gathering information on the messages.

Defense: Use many remailers in a variety of geographical locations, so
that it is unlikely that all of them can be corrupted in this way.


There is another attack scenario, a variation of (9) that
has not really been discussed.

(10)The problem begins with the fact that anonymous addresses are
essentially timeless. While you are safe as long as one remailer is
not compromised ("chain being as strong as its strongest link"), your
anonymous address block is "eternal" in that it lasts as long as the
remailers themselves. 
	Suppose some "determined power" wanted to know who was at the
other end of an anonymous address.  This "determined power" could
coerce each remailer to in turn strip its encryption from the
anonymous address block, and TAKE AS LONG AS IT NEEDED with each
remailer to do this.
	To defend against this, I think remailer secret keys should
expire and BE DESTROYED after a set period of time. When it's time to
expire the old key pair, a remailer could generate a new key pair, and
sign the new public key with the old secret key (assuring it came from
the remailer) and then destroy the old secret key completely. All
remailers would have to do this fairly synchronized, in order for anon
addresses to be useable. (Can't have one key in the chain expiring
unexpectedly).
	Anonymous addresses would then have to be re-generated with the
new remailer keys (and hopefully a new remailer path as well!).

	Hopefully if such a situation ever arose, the keys would
expire and be deleted before the "determined power" could manage to coerce
ALL the remailers in the anonymous address block's remailer chain to
strip off their respective encryption layers.  (coercion/key
theft/whatever..)
(ie "Sorry.. can't decrypt this for you.. the key was automatically
destroyed 6 days ago...")

	This would also help defend against attack #7 by forcing 
the re-generation of anonymous address blocks, with (hopefully)
new remailer chains attached to them.


Other possibilities for increasing the security and the difficulty of
attacks:

(1)	Allow for encrypted header blocks (either in the anonymous
address block or in the sender's encrypted header block) to contain
commands to remailers to split the message into pieces (either just
cutting it up, or ripping it into 2 or more pieces connected by XOR's
or whatever) and send out via different paths (path "forking") to be
reassembled at the end.
	This would make attacks 3,4, and 7 more difficult, and would
not be too bad to reassemble for the anonymous address blocks, but
would be hard to deal with for the sender-anonymity version (at the
receiver end.)


(2) 	Implement a remailer web that is constantly connected via
sockets, with a near-constant-volume encrypted byte stream, with rapidly
changing keys and mixing of fake data and real data.
	This would eliminate the need to pad or batch messages and
would defeat attacks 2,3,4,5,6, and would make attack 7 harder.

	This would also be pretty tough to do, and could put a serious
drain on the computational and bandwidth resources of the remailer
hosts. (student accts would be out.)

Ideas/Comments/Criticisms?

Sorry, this was longer than I thought it would be (trying to be as complete
as I can.)
-Sam

In fact, there is a simple closed form expression for this value,
namely, e^-E(ln p), the inverse exponential of the expected log
probability.  This is exactly e^H, where H is the entropy of the
probability distribution.  e^H is also the expected size of the search
space, were we looking for encryption keys.

On the other hand, this situation is unlike a key search space in that
every value is not equally likely and that the priors are not
independent.  In a phrase, not everybody talks to everyone else, but
everyone who talks talks to someone else.  We can make a baseline
model of a communications graph with probabilities on it.  (This
doesn't take into account state, e.g. conversations tend to happen
alternately.) Most edges on this graph will have p=0, i.e. these two
people have never communicated. Let us remove these null edges. What
we are left with is a sparse graph with lots of clustering (friends of
friends). In this situation, if our message could have gone to ten
million people (say, 7 hops each with threshold 10), it is more likely
that it went to one of twenty or fifty.
Even if you don't know what the graph looks like, you'll know that it
is sparse, and you'll have some idea of what the characteristic
distributions are.  This is exactly the equivalent of studying letter,
digram, and higher order statistics for English and other natural
languages.  The statistics gathered as to the prior distribution will
appear in the observed output unless one has some good idea of how to
'confuse and diffuse' them.

I am pushing an analogy here between cracking codes and cracking
traffic patterns.  I am pretty sure that there are more parallels than
meet the eye.  The appearance of the entropy in the expected number of
recipients may be only the tip of a much larger correlation.

traffic			cipher
=======			======
statistics of		letter frequencies
interconnection		of the plaintext

observed messages	ciphertext

path through		key
remailers

mixing algorithms	encryption

null messages		padding

This whole mix system needs a lot more thought before we'll have an
assurance that it will be secure against sustained attack.
-------------------------------------------------------
On the lighter side, I couldn't resist this next one.

>(8): Correlate messages being sent from person A with messages being
>received a certain time later by person B.  

>Defense: [...] The sender's traffic pattern is
>then constant and no information can be gained from it.
And for the receiver, just subscribe to cypherpunks under several
different aliases.
Eric

>>>>> On Fri, 27 Aug 93 10:14:19 -0700, hughes@ah.com (Eric Hughes) said:

	Eric> Attack (7) is made by an opponent who monitors all
	Eric> network traffic, but has no access to the insides of the
	Eric> remailer nodes.

	Eric> The defense is more subtle, however, than proposed.

>(7): Look at all messages coming out of the first remailer, and
>follow them into their 2nd remailers; take all messages from those and
>follow them on, and so on.  This will eventually lead to a number of
>destinations, one of which must have been the destination of the original
>message.  Over a period of time, look for correlations between destinations
>and sources.

	[...]

>making correlations statistically impossible

	Eric> What is the nature of the remailer path, however, for
	Eric> which we have an assurance that the correlations are too
	Eric> difficult to carry out?  Or to ask a simpler question
	Eric> for a simpler environment where we assume all remailers
	Eric> are equal, just how long does the path have to be?

	Eric> We know that by making the paths "long enough" that we
	Eric> can prevent correlations from becoming significant.  The
	Eric> question is how do we find out what is long enough?

>such an attack (PROLONGED monitoring of all
>remailers) would be very difficult to perform, esp. with use of
>remailer-remailer socket connections.

	Eric> The fact that it would be difficult is not the issue for
	Eric> the theory, but for the practice.  The extremely high
	Eric> cost, however, could be justified for 'national
	Eric> security' reasons against a few targets, or to break the
	Eric> system completely open looking for 'tax evaders.'

	Eric> If our theory is good against an arbitrarily strong
	Eric> opponent, then the system can withstand sustained
	Eric> attack.  If the existence of the system is seen as
	Eric> sufficiently threatening, for any number of different
	Eric> threats, we should plan for a sustained attack.  We need
	Eric> to know what the limits of the capability are and not
	Eric> just guess.

	[.. lots of good stuff about privacy diffusion deleted..]

	You are right of course, we can't just hope that it's "good
enough", but I want to ask if this problem of defending against attack
(7) should be considered a problem for the remailer web to handle at
all. I think this should be a problem for the authors of anonymous address
blocks and sender-anonymous headers blocks, and the software used to
do such.
	NOT that this should not be addressed, but it should not be an
impediment to implementing a remailer web. If we delegate resolution
of that problem (as complex a defense as you want) to software to
create encrypted headers, then people can have as good a defense to
this attack as they deem reasonable. (ie protection against this is
responsibility of remail users rather than the remail net.)

	To delegate this responsibility to the remail users, one could
implement the remailers with the ability to process simple commands
that are revealed when the remailer strips off its layer of encryption
of the encrypted header (or anonymous address block).

	The most important command (for anonymous address blocks)
would be instructions to encrypt the message body with with a supplied
key.  This is to defeat the previously discussed problem of trusting
the remailers themselves (run your own remailer and send mail to anon
address, and look for a copy of your message to pass through.)

	A delay function would be useful also. (ie delay(15000) to
tell the remailer to hold the message 15 minutes before sending on.)

	A command that would make analysis more difficult would be a
random function that could be used to randomize aspects of the
message's path, layered encryption, or time delay.

Ex1:

	After removing its layer of encryption from the message header,
	the remailer gets something like (pseudo header with comment
	lines begin with a #):

	random(3,7463)
#     3 choices^    ^seed
	{
	header-block 1
	header-block 2
	header-block 3
	}
#the header blocks would contain the next remailer to use, the
#encrypted header to send along with the message, and the key to encrypt
#the message with (if this is an anonymous address block we are talking about)

Ex2:

	delay(random(20000,9842))

#this would tell the remailer to wait between some minimum and
#20000 seconds to send the message along (along with the seed of 9842 for 
#the random function.



The randomness should be seeded by both the message and the remailer,
and if using randomly selectly keys to encrypt with (from a list),
some indication of which one was used (1, 2, or 3 etc) should be
included with the message, perhaps tacked onto the end of the message
after encryption (in a remailer->recipient data block ?), possibly
encrypted to the anonymous recipient using their key (included in this
layer.)

Commands could of course be nested, to create as complex a routing
specification as desired.

While this may seem overly complicated, most of it could be
handled fairly transparently by the user software.

	This approach ("smart messages") would have the possible
drawback of very large anonymous address blocks (containing multiply
encrypted, command driven headers, path branches etc.)

	A response to this could consist of "anonymous address
servers" which which the user software could, when mailing to an anon
address (ie "anon7462849") query to get the associated anonymous
address block (which being signed by the anonymous recipient would
assure its authenticity) and connect to the first remailer in the
chain as specified by the anon address block, all handled
transparently, possibly including handling sender-anonymity header
work as well.
	This would have several added advantages. The first would be
the simplification of handling anonymous address block- all the user
would need to know is the name and public key of the anonymous persona.
	It would also assist in the remailer key-expiration defense I
proposed previously. The anonymous address server could be synched
with the remailers to erase all the anonymous addresses when the
remailer keys are replaced.

	Anonymous address creation software could be written to grab
the new public keys to all the remailers from somewhere (maybe even
the anon address server itself ?) which were signed with the old
secret keys to assure their authenticity, and construct a new
anonymous address block, which would then be encrypted with the
anonymous address server's key, and submitted to the server via
sender-anonymous mail.
	Anonymous recipients could then also alter their anon address
header as often as they wanted (although being forced to when the
remailer keys expire), changing the path specification to frustrate
statistical path analysis.

	As ideas progress regarding how to defend against statistical
analysis of the message traffic, software to create anonymous address
blocks and construct sender-anonymous headers could be correspondingly
improved, without having to rewrite the remailer software.



I know this appears to be quite a bit of software work, but if and when
we get the protocols agreed upon, *I* will work on it as much as I can,
and I hope others would work on it also (whatever system is accepted/agreed
upon -- be it this or something else.)

The software system I've proposed includes (so far):

Remailers:
	Socket connections for talking to other remailers;
	Encrypt using other remailers keys to insure that
		two identical messages going into a remailer come out
		differently (random session key).
	Ability to handle simple command language and perform operations
		on the message and header. (picking one of several paths etc.)
	Ability to handle all the necessary decryptions- header encryption
		using its pubkey and random session key based encryption
		from previous remailer.
	Message batching (to be combined with "delay" function somehow?)
	Message padding (to be handled inside of encryption-to-next-remailer?)


Mailer:
	Ability to handle construction of sender-anonymous
		nested encrypted headers possibly using command language.
	Ability to communicate with and verify output of anonymous
		address block servers.

Anonymous Address Creation Software:

	Ability to obtain current remailer keys.
	Generate set of random keys for remailers to use.
	Intelligent creation of "smart header" and random anonymous
		mail path(s).

Anonymous Mail Reader:

	Ability to parse message and determine which keys were used
		by the remailers and decrypt layers to get message.


	Such a system would not have to be implemented all at once.  I
think the first steps would be remailer socket communication, and
simple anonymous address and sender-anonymity header construction
software.


Comments/Suggestions/Improvements/Criticisms necessary and welcome.

(yeah I know.. it's easy to "propose" something -- but I'm willing to
actually invest significant effort and time in it also, for what it's worth.)

Sam Pigg                                  "UnAmused" by the USGovCo.
b44729@achilles.ctd.anl.gov     <or>     dt1acaca@cfraix.cfr.usf.edu
PGP Key Fingerprint: ED A7 49 33 65 90 9A BD A4 E4 C5 92 5A 00 BC 6C

Samuel Pigg wrote:

>	A delay function would be useful also. (ie delay(15000) to
>tell the remailer to hold the message 15 minutes before sending on.)

Well, I tried to implement this on a test remailer as follows:

1) file incoming mail in a spool directory
2) at midnight, pick a random file in the spool directory, operate on
   it, mail it out, and delete
3) keep on going until the directory is empty

Naturally, you could make the interval larger: say a week.

With no root privs on the machine, I tried using the at command to
perform the above function and then reschedule itself for tomorrow.
Problem: if the machine reboots then the mailing out portion is killed.

I'll fiddle with it some more.

>	Socket connections for talking to other remailers;

Yes!  This might help avoid some log files.

>	Encrypt using other remailers keys to insure that
>		two identical messages going into a remailer come out
>		differently (random session key).

If you add random stuff to the end of an encrypted message and encrypt
again, when you decrypt will PGP throw away the ending junk?  If so,
maybe the routing software could include random bits between each
nested encryption instead.

If the remailers encrypt then the operators will have to keep adding
to the remailer's pubring.

-- 
/--------------------------------------------------\
| Karl L. Barrus: klbarrus@owlnet.rice.edu         |
| D1 59 9D 48 72 E9 19 D5  3D F3 93 7E 81 B5 CC 32 |
\--------------------------------------------------/

>With no root privs on the machine, I tried using the at command to
>perform the above function and then reschedule itself for tomorrow.
>Problem: if the machine reboots then the mailing out portion is killed.

A user's crontab is not deleted at reboot, to my knowledge.  You could
simply run a cron job to schedule mail delivery.  (If you deliver on
cron, you don't get an even distribution of delivery times, unless you
use a much more frequent cron.)

Eric

>>>>> On Fri, 27 Aug 93 05:52:43 CDT, b44729@achilles.ctd.anl.gov (Samuel Pigg) said:

Samuel> Correct me if I'm wrong, but as I see it, there are two goals
Samuel> for the remailers:

Samuel> (1) 	Anonymous addresses to which mail can be sent, but the recipient
Samuel> 	is unknown and cannot be determined (receiving anonymous mail).

Samuel> (2)	The ability to send mail to someone without anyone (including
Samuel> 	the recipient) determing that you did so (sending anonymous mail).

Samuel> Number 2 can be mostly taken care of with nested encryption of mail headers.


This is an excellent observation which many people seem to ignore when
thinking about anonymous remailers.  It's understandable why, because
achieving both of these goals at the same time is really quite
difficult.  I've been working on a system to accomplish this for
several months now, and it's quite complicated.  I call it SASE for
Self Addressed Stampable Envelopes.  Actually a new name that doesn't
imply prepaid postage would be nice if anyone can think of a catchy
one...

Samuel> To construct an anonymous address block might be something like:

Samuel> 	Anonymous Anne wants an anonymous address.
Samuel> 	First she generates a set of N keys (IDEA, DES or .......

That's basically the way SASE works.  It's important that some of the
keys be public key pairs, however; as you need to be able to publish
one half of a key, and seal the other half for an unpublished remailer
to decrypt with.

One thing is certain, these protocols are not simple.  We definitely
need people thinking about them...

-eric messick

>>>>> On Fri, 27 Aug 93 20:53:51 -0700, eric@Synopsys.COM said:

>>>>> On Fri, 27 Aug 93 05:52:43 CDT, b44729@achilles.ctd.anl.gov (Samuel Pigg) said:

Samuel> Correct me if I'm wrong, but as I see it, there are two goals
Samuel> for the remailers:

Samuel> (1) 	Anonymous addresses to which mail can be sent, but the recipient
Samuel> 	is unknown and cannot be determined (receiving anonymous mail).

Samuel> (2)	The ability to send mail to someone without anyone
Samuel> (including 	the recipient) determing that you did so
Samuel> (sending anonymous mail).

Samuel> Number 2 can be mostly taken care of with nested encryption of
Samuel> mail headers.

	[...]

Samuel> To construct an anonymous address block might be something like:

Samuel> 	Anonymous Anne wants an anonymous address.
Samuel> 	First she generates a set of N keys (IDEA, DES or .......

	eric> That's basically the way SASE works.  It's important
	eric> that some of the keys be public key pairs, however; as
	eric> you need to be able to publish one half of a key, and
	eric> seal the other half for an unpublished remailer to
	eric> decrypt with.

I don't see why some of the keys need to be public key pairs.
The intermediate encryptions done by the remailers are only to be
undone by the anonymous recipient correct?

So why would one part of the keys need to be published?
(the anonymous address block would have these keys sealed in the various
nested encryption levels, as you said.)

	eric> One thing is certain, these protocols are not simple.
	eric> We definitely need people thinking about them...

..and discussing them! (as we are doing now.)

-Sam