On Fri, 3 Sep 1993 21:13:47 PDT, doug@netcom5.netcom.com (Doug Merritt) said:
Doug> sameer@netcom.com (Sameer Parekh)
install-script I can add this little feature. Which newsgroup? Should someone create an alt.remail? How exactly would it be implemented? I'm thinking that simply the user would do: [...] And the remailer would post to alt.remail:
Doug> There are two problems here. One is that the remailer Doug> exposes itself and defeats traffic analysis avoidance. Not necessarily. If the "post this message to alt.remailer" command for a smart message were executed via splitting off another message with its own encrypted header and path through the remailers to an anonymous posting service. (as suggested by miron@extropia.wimsey.com) Doug> The other is a standard transaction processing sort of Doug> problem; the posting to alt.remail might fail even Doug> though all else worked. I agree this could certainly be a problem (esp. executed as above.) [..] Doug> b44729@achilles.ctd.anl.gov (Samuel Pigg) said:
By breaking a message into pieces and sending them via different paths to the same destination ("path forking"), this can only make traffic analysis easier, because all the pieces lead to the same destination, and you can follow any of them to get to the anonymous recipient.
Doug> Depends on how it's done. As stated this analysis Doug> implies that traffic analysis is *always* possible, Doug> since after all, the message must somehow make it to its Doug> destination. In other words, I disagree. No I'm not implying that. But there really isn't any way doing that could make such an analysis *harder*, as by splitting pieces of the message off, you have multiple parts all going to the same destination. This gives the attacker redundant paths to follow, and if the attacker can trace *any* message, he can discover the identity of the recipient. There would be no "dead-ends" for the attacker. (when I say "follow" I don't necessarily mean follow in a literal sense, but any traffic based statistical analysis.) Doug> This needs to be done in conjunction with other standard Doug> cypherpunk fare, of course. The major design problem Doug> I've had is not with security, it's with fault Doug> tolerance. Statistical fault tolerance is available, but Doug> I prefer leaving that kind to the underlying base Doug> systems and networks, and trying to find a top level Doug> algorithm that is 100% guaranteed to either work or Doug> report failure, so long as the host systems/networks Doug> don't fail undetectably. A handshake ACK of receipt Doug> would help, except that it might not get back even if Doug> the original reached its destination. I agree this is the major problem, with the current state of the remailers, but it may not be a problem with a stable remailer web and an "anonymous address server" (see my long laborious boring posts regarding this from about a week ago.)
follow them all), as only one will arrive there and the rest would die after a number of remailer hops.
Doug> This is actually less safe than an approach which Doug> requires multiple pieces to arrive via multiple paths. Doug> Bad luck might leave your one path completely in the Doug> hands of bad guys (posing as cypherpunks, let's say). I don't think so. This way there is only one (or a few) paths that actually would lead to the recipient, and many "blind alleys" for an attacker to follow. With the multiple-pieces-same-destination scheme *any* one path would be enough to determine the recipient.
I really think that non-deterministic "smart messages" are the way to go here.
Doug> This I agree with; but the way that is done is critical.
A simple command language for the remailers would allow the header construction software already being worked on by ebrandt@jarthur.Claremont.EDU (CRM) and others to use tricks like this to defend against attacks.
Doug> Cool. More info? I'm not saying that CRM actually uses a command language (it can't-- nothing has been agreed upon/worked out yet!) but tools like CRM would be able to use a remailer command language to tailor the message's (or anonymous address block's) anonymity protection. See that same long, boring post I made about a few suggestions for what such a language could contain/be useful with.
The defense complexity would be a function of the users' header construction software and needs. People who need "minimal" anonymity would have simpler anonymous address blocks, as compared to those who require "serious" anonymity, and the remailers themselves would have a lighter load (not having to implement very serious security for *all* messages-- just those that need it).
Doug> Strongly agree. Doug> BTW I consider this emphasis on batch mail to be short Doug> sighted. I'm designing for interactive cyberspace. I Doug> have a complete algorithm in mind, except I think it Doug> still needs some more OLTP wisdom added in. A remailer command language could include instructions to specify how long to hold this message (possibly to be combined with some remailer batching functions.) [..] Sam Pigg dt1acaa@cfraix.cfr.usf.edu samp@renoir.cftnet.com <or> b44729@achilles.ctd.anl.gov PGP Key Fingerprint: ED A7 49 33 65 90 9A BD A4 E4 C5 92 5A 00 BC 6C