1994-07-13 - Encrypted, Chained Reply Blocks

Header Data

From: nobody@ds1.wu-wien.ac.at
To: cypherpunks@toad.com
Message Hash: 7ecd401d3dd038d00afd5d10e1d673769cac169fa6392c6d142dfd442a530c3a
Message ID: <9407130247.AA08901@ds1.wu-wien.ac.at>
Reply To: N/A
UTC Datetime: 1994-07-13 02:48:32 UTC
Raw Date: Tue, 12 Jul 94 19:48:32 PDT

Raw message

From: nobody@ds1.wu-wien.ac.at
Date: Tue, 12 Jul 94 19:48:32 PDT
To: cypherpunks@toad.com
Subject: Encrypted, Chained Reply Blocks
Message-ID: <9407130247.AA08901@ds1.wu-wien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain


I noticed a message posted here, anonymously, with an "encrypted
reply block" (ERB) attached to the end of it.  Instructions were 
given that to reply to the message, the block was to be pasted at 
the very beginning of the reply, which was then to be sent to a 
certain remailer.  The block started with the usual "::", 
followed by and "Encrypted: PGP" line typically used with chained 
remailers.

While I don't know the specifics of that particular ERB, would it 
be possible to chain a REPLY through several remailers, such that 
the body of the reply was sent along in the clear through each 
link of the chain, but the final destination address was only 
visible to the operator of the final link in the chain?  This 
would require that after the "Encrypted: PGP" block, any appended 
plaintext would also be sent along by each remailer and not 
discarded.  Which remailers allow that?

Hypothetically, it would seem that one could take an "empty 
message", using the "CHAIN" utility to chain the "message" 
through remailers A,B,C,D, encrypting it at each step, placing 
the resulting block in the message body with instructions that 
the resultant block must precede any replies, which must then be 
sent to remailer "A".  Alternatively, instead of an empty 
message, a single, unique, identifying line could be used as the 
message.  This would allow a person to generate multiple ERBs and 
know which one had been used for any given reply.

One weakness I can see in such a scheme is that traffic analysis 
would be a bit easier, since the plaintext of the reply would be 
visible at each step.  Also, there would be a potential for "hand 
tracing" the reply to its destination, assuming each remailer 
operator cooperated, by sending a personal message to operator 
"A", with the ERB attached, asking him/her to decrypt the next 
link destination, then forward the message to the operator of the 
next link with a similar request, and so on, requesting that the 
last operator in the link report the ultimate recipient's email 
address to the requestor.  This would potentially be easier than 
tracing a message the other direction, since by the time the 
message arrived, information necessary to trace it backwards 
might have been already deleted at one or more of the chained 
remailer sites.

Any thoughts or suggestions?  Are there any further obvious 
weaknesses in this scheme that I may have missed?





Thread