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
Attack (7) is made by an opponent who monitors all network traffic, but has no access to the insides of the remailer nodes. 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.
Let us assume that these remailers have the basic characteristics of mixes: encryption rewriting, size quantization, and message reordering. Furthermore, let us assume that the defense of using 'large' chains of 'popular' remailers is being used.
With enough mixing at each stage of the chain, the number of possible destinations will become astronomically large,
The possible number of destinations should increase exponentially with each hop. If gather-and-rearrange mixing is done, then the number is the product of the rearrangement thresholds for each remailer. If a radioactive decay model for reordering is used, then it is the expected value of the number of destinations which grows exponentially, that is, the possible number of destinations (those with non-zero probability) grows faster that the expected value of the number of destinations. They are both exponential, but one has a larger base than the other. What is more important than the reordering algorithm is that the expected number of destinations grows exponentially with the number of hops. There will be correlations, but with linear increase in cost we can get rid of them, we hope.
making correlations statistically impossible
What is the nature of the remailer path, however, for which we have an assurance that the correlations are too difficult to carry out? Or to ask a simpler question for a simpler environment where we assume all remailers are equal, just how long does the path have to be? We know that by making the paths "long enough" that we can prevent correlations from becoming significant. The 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.
The fact that it would be difficult is not the issue for the theory, but for the practice. The extremely high cost, however, could be justified for 'national security' reasons against a few targets, or to break the system completely open looking for 'tax evaders.' If our theory is good against an arbitrarily strong opponent, then the system can withstand sustained attack. If the existence of the system is seen as sufficiently threatening, for any number of different threats, we should plan for a sustained attack. We need to know what the limits of the capability are and not just guess. I've been thinking about an invariant for communications systems proof against traffic analysis which I call 'privacy diffusion'. The privacy diffusion is a probability distribution over possible recipients. One characteristic of the privacy diffusion is the expected value of the number of different recipients. This is a good first measure, but I suspect it won't be enough. The expected number of recipients is multiplicative in the diffusion per node, as described above. If different downstream nodes have different mixing thresholds, they'll need to be weighted. Since the system is multiplicative, the weighting should be by geometric mean, i.e. a downstream node with probability 1/10 should multiply by the 10th root of its own threshold. One can see that if all the downstream nodes have equal likelihood and identical thresholds, that this formula degenerates into the simple one above. 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 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
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
participants (5)
-
b44729＠achilles.ctd.anl.gov -
eric＠Synopsys.COM -
hfinney＠shell.portal.com -
hughes＠ah.com -
Karl Lui Barrus