[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why encrypt intra-remailernet.
- To: [email protected]
- Subject: Re: Why encrypt intra-remailernet.
- From: [email protected]
- Date: Sat, 4 Feb 1995 18:42:40 -0800
- Comments: This message is NOT from the person listed in the Fromline. It is from an automated software remailing service operating atthat address.THE PORTAL SYSTEM DOES NOT CONDONE OR APPROVE OF THE CONTENTS OF THISPOSTING. Please report problem mail to <[email protected]>.
- Sender: [email protected]
> Date: Sun, 29 Jan 1995 17:56:34 -0800
> From: Hal <[email protected]>
> Of course it was Chaum himself in his 1981 paper (which I think is
> available from the CP FTP site) who described the duplicate-message
> attack. I don't see that inter-remailing encryption helps much,
> because the attacker can still notice that whenever they inject
> message A, _something_ goes to Bob. The real solution, as Chaum
> pointed out, is that the remailer must reject duplicate messages,
> even when separated by days. Doing this without keeping a database
> of all messages ever sent is left as an exercise.
Perhaps the postage could integrally contain the request-remailing-
to field. Supose the postage were <e-money, to-address> encrypted to
the remailer. Then replayers would want to copy the to-address into a
new piece of postage. But, we assume, they can't figgure out what it
is because they don't have the key for the remailer.
If the remailer issued it's own non-blinded stamps, the remailer
would have to keep a list of canceled stamps. (For as long as that
series of stamps remains valid.) If the remailer used Chaumiam e-cash
no logs would need to be kept at all.
> Another aspect worth mentioning is that message splitting can make
> the kinds of statistical correlations that Wei Dai was looking at
> more of a danger. [...] Ideally you'd want to dribble them out at
> some standard rate, a rate at which you always send a message
> whether you have something to send or not. But this may introduce
> unacceptable latency.
If everybody ran a second level remailer, and if they always
forwarded something (of very nearly the same size) when they recieved
an encrypted message, then without compromising the users machine it
would be imposible to say when a message was delivered. Some of the
messages forwarded would need to be junk. Is there a polite way to
send mail to a remailer, and ask it to junk the mail? Some of the
messages forwarded would have to be 'part n of m' messages.