Tim May writes concerning the need for "new and improved" cypherpunk remailers: ( His comments in " " or after > )
FEATURES NEEDED IN A SECOND GENERATION REMAILER:
I. DIGITAL POSTAGE Requests for remailing would be accompanied with some form of digi-cash token, with the amount equalling (number of hops requested X price per 'stamp'). The remailers would keep the token that came with the message, and substitute one equalling # stamps -1 that would be digitally signed by it. This new token would be passed down the line, with each remailer keeping the tokens that come in and substituting their own. The tokens that are kept would be sent to a central remailer clearinghouse which would settle accounts. (See * at bottom of msg for further details on the clearinghouse.)
II. JUNK MAIL SCREENING I really don't know how best to accomplish this, either.
III. IDEAL DIGITAL MIX I'm not sure that we can achieve an 'ideal Chaumian digital mix' of messages at this time, but I have a few ideas on how we can improve on what is presently in place. Instead of padding individual messages to improve diffusion, batch several messages together to reach some 'standard' remailer msg length of n bytes, and then encrypt the batch with the next remailer's public key. Noone looking at the message as it leaves the remailer will be able to determine what # of msgs are in the batch, or which particular msgs are present (assuming they don't possess the private key of the remailer to which the batch is being forwarded). The individual msgs in a batch could be seperated with some standard remailer command, e.g.
:: Cut here ------------ When the batch arrived at the next remailer, it would be decrypted and the Individual msgs seperated and placed in the remailing queue. Latency could be set by the customer with a command such as: :: Hops = x, Final = Remailer Z [ where x =1-9, and Z = either the remailer address or some alias that could be looked up in a table. 'Final' would be used in place of the nested encryption used now, so that the msg sender would only have to encrypt the final destination of his msg once. The # of Hops would be decremented by one as they were processed by each remailer. Remailers would send a msg to any other remailer randomly, except when Hops = 1, and would then forward the msg to Remailer Z. So I envision a typical msg looking like this: a. The instructions for # of hops and final remailer hop b. The instructions for final destination. c. The msg itself. c would be encrypted as the sender chooses, and then b + c would be encrypted using the public key of remailer Z ( Z to be chosen by the sender of the msg). a would be in the clear, or a+ b+ c could be encrypted with the public key of the first hop in the remailer chain. Of course, all of this ( a, b, and c ) could be done in the clear, but that would place your msg is jeopardy at each and every hop of being intercepted and read. That might be acceptable to some users, though its not very robust. Messages would be batched into groups by taking first m number of msgs whose lengths add up to the standard length n. Diffusion could be increased by shuffling the queue as each message entered the remailer. Latency and diffusion could be increased by inserting "null" msgs into the mix. A few months ago Eric Hughes mentioned that Hal Finney was forwarding list msgs encrypted to some unkwon number of persons. If he is still doing this, these msgs could be inserted into the mix by remailing each msg to _one_ of the remailers in a random fashion. These msgs could contain a command such as :: Hops = {1-9}; Final = Dev.Null They would be remailed within the remailer loop until Hops = 0, when they would be sent to the bit bucket, having served their purpose.
IV. NO LOGGING The important part of this is that the policies of individual remailers should be clear on this point, so that individuals can choose the initial and final remailers if that policy is a concern to them. As Tim says:
" Sites which log but say they _don't_ is of course the real issue in the long run....I'll save this interesting topic for another article, maybe. Just be aware that this kind of "collusion" (not exactly, but this is what the literature calls related behaviors) is not easily solved with existing remailers.) "
V. HARDWARE-BASED REMAILERS No particular expertise here. I'll this to those that do.
VI. MARKETS I think it will work better if the routes are chosen randomly by the remailers ( except for final hop, see above ), as this process is more "user friendly". "Pinging" could be centralised into one clearinghouse (*see below), which handled settling of postage accounts between remailers.
VII. STANDARD FORMATS Needed, but to be decided upon. If noone else volunteers, I am willing to host a moderated Cypherpunks sub-list whose topic would be limited to remailers. Moderated, because I don't have the facilities to run an automated mail reflector and so that the signal to noise ratio is kept high enough that contributors don't drop out due to Detweiler or other noise sources.
VIII. RATINGS AGENCIES I think that diversified sources of info for "consumers" of remailers is a "good thing", but there should be a centralised clearinghouse which would concern itself solely with reconciling postage accounts and with "pinging" the remailer net at regular intervals and sending out msgs to remailers to avoid sending packets to sites which are not responding in an appropriate amount of time. ( "Appropriate" to de determined .)
IX. DIVERSE SITES Tim writes: "I also think we also need "virtual sites" which are themselves only accessible by remailers." I agree.
"Other names for these sites might be "sacrificial sites" or "digital cutouts" " This can be accomplished now using the commercial site America On Line (AOL), which permits its customers to have a half- dozen or so distinct sign-on names per account. So you could run a site called "Remailer_17" (with apologies to Wm Holden) which received msgs to be remailed. These msgs could be downloaded, processed, and then uploaded through a different name entirely, "Fnord_OMF" or whatever. Unless the <insert favorite bad guy organization here> monitored _all_ possible alias accounts, they would not be able to do traffic analysis on the remailer network.
X. ATTEMPTS TO BREAK REMAILERS I'll leave discussion of this to those with greater knowledge of hacking and/or cracking than myself.
* CLEARINGHOUSE The clearinghouse would not be accessible to users of remailers, but would be internal to the remailer network and handle accounting and "pinging" of remailers. Accounting example: I send a msg to remailer A, requesting # Hops = 3 and Final = remailer C. I enclose at the top of the msg digi-cash equalling the cost of three "stamps". ( One stamp for each hop.) Remailer A keeps the original digi-cash token, and substitutes one signed by it equalling two stamps. The msg is remailed to remailer B, which keeps the token supplied by remailer A and substitutes one signed by it equalling one stamp; remailer B notices that the # Hops now = 1, so it remails the msg in a packet to remailer C. Remailer C keeps B's token, and sustitutes nothing since this is the final hop for this particular msg. It then decrypts the msg and follows the remailing instructions encrypted in the "envelope". At the end of some accounting period ( day, week, month, depending on number of msgs passing through the system ) all remailers would forward their accumulated tokens to the clearinghouse, which would credit their accounts with the tokens received and debit them for the tokens sent out. The bookkeeping would get fucked up by lost transmissions, so that would have to be addressed at some point to ensure that remailers didn't just bit bucket incoming msgs and keep their stamps. The clearinghouse would also "ping" the remailers in the network at regular intervals and issue "route around" commands to the remailers if one or more sites didn't respond in a timely fashion. Thats all for now. Jeff trestrab@gvsu.edu