December 2003 - cypherpunks-legacy

Re: lwall
by MathWorks Autoresponder 17 Dec '03

17 Dec '03

Your Usenet test article was received on Mon Feb 6 23:50:01 EST 1995 here at The MathWorks, Inc. in Natick, MA. Natick, MA is about 20 miles west of Boston, MA. You are receiving this message because you posted a test message to one of the *.test newsgroups. The MathWorks' news admin can be reached via e-mail at usenet(a)mathworks.com. Please note that we do not offer news access to sites outside of our organization. If you want to suppress this message in the future, include the word "ignore" in the Subject: header of any subsequent articles posted to *.test. You could also post your test articles with a Distribution: header of "local" to prevent them from leaving your local machine, or you could also ask your local newsadmin to create a local *.test group that will not propagate outside of your organization. All headers plus at most 10 lines of user text from your original article are reproduced below for your perusal: Path: news.mathworks.com!zombie.ncsc.mil!news.duke.edu!godot.cc.duq.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!agate!overload.lbl.gov!emf.emf.net!hilbert.dnai.com!nbn!miwok!news.zeitgeist.net!ack.berkeley.edu!not-for-mail Subject: lwall Message-ID: <PINE4545-dhfsdkjc(a)ack.berkeley.edu> NNTP-Posting-Host: ack.berkeley.edu Organization: cypherpunks Lines: 2 From: cypherpunks(a)toad.com Distribution: world Newsgroups: alt.test Date: 6 Feb 1995 19:34:19 GMT

1 0

"encrypt tcp connections" hacks
by strick at The Yak 17 Dec '03

17 Dec '03

Perry, could you enumerate them? I take your opinions more seriously than perhaps I should, so I want to understand what you're saying. I'm not doing this to re-invent the wheel. I'm doing it because I need it, and nothing else is working very well for me. I'm doing it because I don't see anything that's easy-to-use in wide use today. I don't just want one or two encrypted applications -- like the Kerberos telnet and rcp -- but something to transparently provide privacy for all TCP sockets -- like SMTP sockets between (re)mailers, NNTP, X11, FTP, MUDs, etc. Let me name the ones I can think of. 1. Matt Blaze just announced one. As always, he has the best crypto. But his world interface seems to be a hacked up script.c. If I lift his crypto, and make it a standard module in Skronk, I can reuse 90% of his good work. 2. Kerberos4. I use Kerberos4 between home and work all the time. However the only command I have that actually encrypts the session is the "rlogin" replacement. (But I sure use it, even if it's just DES.) Also Kerberos administration is a nightmare. I'm a fairly knowledgeable crypto hacker and unix system administrator but honestly I don't understand what I did. If it weren't for the Cygnus installation manuals giveing line-by-line instructions, I wouldn't have made it. I've taken the reference manuals to bed with me several times, but still haven't gotten a grasp of how to fully use it. And the reason big providers like The Well and Netcom won't run kerberos (or at least not the last time I asked) is that they would have to hire another person just to do the password management etc. Skronk should be "just plug it in and it works". There should be no reason why big providers can't offer it as an option. 3. Kerberos5. I've been unable to build Kerberos5 on my sun3. Honestly. To build it, I have to have ISODE, which seems to be some enormous ISO thing that I haven't been able to build. Again, not too encouraging for your average unix sys admin. 4. The new telnet program with Telnet Options for authentication and encrytion. Well it won't do encryption unless you can get the authentication done, and so you're back to problems 2 and 3 above. I couldn't get it to work in an evening, and decided the world needed something better. Also even if it did work, it's only Telnet. None of the other apps I named above can use it. 5. Standards for IPng. Vapor, as far as I know. Is there any usable code, that works in IP this generation? I think it comes down to the fact that, of these, only Skronk and Blaze's software use a Diffee-Hellman -like Key Exchange so that administration stuff doesn't have to be done by humans and footnet. The real value I'm adding is not the crypto. It's the packaging. When I'm done it should be possible to skronk all your current clients and servers by just overriding the shared library libc.so, running a skronk map UDP daemon, and customizing a configuration file to tell the daemon what to say. ================= As for the UDP service: > UDP won't get through most firewalls. > > Build in support for non-transparent firewalls (ie: telnet gatekeeper, > c sys port). UDP packets are for automatic configuration of skronk maps. Skronk maps could be announced other ways too -- including via manual configuration, where you put skronk maps in your SKRONK_CONF environment variable. I may have to spend more effort on this than I wanted to. I have a SKRONK_CONF variable, and an option to say "dont ask the UDP skronk map daemon" about this port, just skronk it -- but right now it's only dependant on port number, not on the IP address too. This can be fixed. > UDP Port 333 - does this imply you need to be root to use it, > at least as a server, or are only TCP ports typically root-limited > for low-number ports? > Bill You need to be root to install it properly on your system, for the skronked services to become bona fide system services. Users should not be able to hijack SMTP and TELNET connections to a site unless they're root. For people who run their own web server on a nonstandard port on a machine that someone else administers -- we're back to the manual configuration method. Maybe we can build a PGP service with signed certificates to collect nonstandard skronked services. But really I think these services will be marginal. I had thought about using DNS TXT records. But I decided against that because a *lot* of people have autonomy over their workstation on the net, but not over their DNS records. Linux boxen in dorm rooms come to mind. Or anyone who puts a new machine on someone else's ethernet, grabbing an IP address via ARP. ================= Thanks to everyone for your comments. The discussion question is -- if we have so many hacks already -- howcome they're not in use. I hope I found the reasons and addressed them. The firewalls issue bugs me a bit. Would using a well-known TCP port instead of the UDP port fix the problem? I don't think so. Firewalls will block my new TCP port as well. Matt Ghio's project to tunnel through the telnet port sounds good. Of course, that defeats the purpose of the firewall, which is not my aim. My aim is to work with the internet and within its policies, so it can get widespread use. How much of skronk works today? I'm nearing alpha of a version that's hardwired to do DH exchange (using RSAREF2.0) and IDEA CBF (stolen from PGP sources) for the symmetric encryption. But I broke it recently when I added hacks for servers to fake select() listening on both skronked and normal ports, when the program only thinks it's only listening on normal ports. I gotta go ... strick ================== p.s. need some wizard-level help here. I use syscall(2) when I reimplement read() write() connect() accept() etc. on SunOS. On LINUX I borrowed code from the libc sources. On HPUX and Solaris and AIX I'm having difficulty finding a way to do what system calls do, without using the manufacture's packaging. any help would be appreciated.

8 10

Re: New directions in anonymity (needed)
by Hal 17 Dec '03

17 Dec '03

From: Noyb, anonymous-remailer(a)shell.portal.com > So, lets look at the > cost of ataining anonymity. For U people to communicate M bits (total > -- 2 people each sending 2 bits is M==4) s/r anonymously takes O(U*M) > bits multicast bandwidth for Chaum's DC protocol, but the repool > protocol uses only O(h*M) bits narowcast bandwidth plus O(M) bits > multicast bandwidth (Where h is the average number of remailer hops, > expected to be a constant wrt U and M, smaller than U, and much smaller > than M). The repool could actually be somewhat worse than this. Wei has shown that if you don't send every tick then statistical information builds up surprisingly quickly to link senders and probable receivers, especially if there is a pair communicating frequently over a long period of time, arguably one of the main forms of usage of these nets. So everyone has to send all the time at the rate of the maximum per-user rate accepted by the remailers (say, one packet per tick). If this rate is considerably above the actual average communication rate of a given user then this will be much higher than O(h*M) (although granted it will not scale directly with U, increasing U will increase the desired packet rate that would satisfy, say, 90% of users). Hal

1 0

a simple explanation of DC-Net
by Wei Dai 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The DC-Net is not very easy to understand. I'll try to explain the most important parts of the concept as simply as I can. Let's say there are a number of participants in a DC-Net. Each participant shares a different one-time pad with each of several other participants. At most one participant can send one bit through the DC-Net per "round". How does this work? For each round i, a participant takes the i-th bit of all the one-time pads that he has and XORs them together. If he doesn't want to send a bit, he just broadcasts the resulting bit to every other participant. If he DOES want to send a bit, then he broadcasts the XOR of that resulting bit and the bit he wants to send. When everyone has done this, each participant takes all of the bits that has been broadcasted, and XORs them together. This last action produces the output of the DC-Net for the i-th round. Suppose for the first round nobody wants to send a bit. Since each one- time pad is known by 2 participants, the first bit of each pad has been XORed into the final output twice. Since anything XORed by anything twice equals itself, these two XORs cancel each other out. And since nothing else has been XORed into the output, the output must equal 0. If one participant wanted to send a bit, however, then something else HAS been XORed into the output. Since all the bits from the one-time pads cancel out, the output equals the bit he wanted to send. Wei Dai P.S. I realize someone has probably written something like this already, but I hope this explanation helps someone who is still puzzled. If nothing else, it serves as a sanity check on my own understanding. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzbKfTl0sXKgdnV5AQGTpwQAtGe5zl91MgA/ayzBGo/DLXh7NyTDSw00 h/qZZxh2U9HoNFLHMMiHV64PYE8poJlCH8kLDY+XZlv1phoiBtMnc2AehN5XVJmr YCQ77rH9vp6yk6SZ5F7HV/UNIIQj6TkW806OZP7LlgUrXWPZdCSYGPh7n60J4TkD RaspzTgFcUk= =ml6y -----END PGP SIGNATURE----- E-mail: Wei Dai <weidai(a)eskimo.com> URL: "http://www.eskimo.com/~weidai" =================== Exponential Increase of Complexity =================== --> singularity --> atoms --> macromolecules --> biological evolution --> central nervous systems --> symbolic communication --> homo sapiens --> digital computers --> internetworking --> close-coupled automation --> broadband brain-to-net connections --> artificial intelligence --> distributed consciousness --> group minds --> ? ? ?

3 2

Re: lwall
by Xpat Autoresponder 17 Dec '03

17 Dec '03

DO NOT PANIC! REMAIN CALM! READ *ALL* OF THIS MESSAGE BEFORE GETTING UPSET! Your Usenet test article was received here at the news gateway machine for the Pohang University of Science and Technology in Pohang, South Korea. The Xpat newsadmins can be reached via e-mail at usenet(a)xpat.postech.ac.kr. Any reply to this message will be dropped into the bit bucket, and never be seen by a human. Please note that we do not offer news access to sites outside of our organization. If you're a newsadmin and you'd like to run your own autoresponder, this one is available from ftp://ftp.cccd.edu/pub/usenet/innautorespond. If you want to suppress this message in the future, include the word "ignore" in the Subject: header of any subsequent articles posted to *.test. You could also post your test articles with a Distribution: header of "local" to prevent them from leaving your local machine, or you could also ask your local newsadmin to create a local *.test group that will not propagate outside of your organization. There are typically 5 possible reasons why you were sent this e-mail message: 1) You intentionally posted a Usenet news article to a *.test newsgroup. These newsgroups exist so you can verify that your articles are being propagated correctly. When your article arrives here, we send you this message as confirmation. We will only send you ONE e-mail reply for each of your test articles that we see. 2) You unintentionally posted a Usenet news article to a *.test newsgroup. This is a bit of net.childishness caused by a Followup-To: header directing all replies into a *.test newsgroup. This is done by somebody upset with the content of a discussion thread who wants to "punish" anybody who replies to his message. Your reply will be sent to *.test instead of the original newsgroup, and you will start receiving autoresponder messages similar to this one that you didn't ask for. To avoid this in the future, look for a Followup-To: header and make sure it's appropriate before replying to any articles. 3) You were a victim of a Reply-To: header directing your e-mail into a *.test newsgroup via a mail->news gateway. Similar to 2) above. 4) Somebody has forged a posting in your name to one of the *.test newsgroups. To avoid this in the future, use better net.etiquette and you will make fewer net.enemies. If you want to try and identify the forger, use the following procedure. Make a legitimate posting to the same *.test newsgroup that the forger used. We will send you an e-mail reply. Compare the Path: header from this legitimate reply with the Path: header from the forgery. The front part of the two headers will be the same or topologically similar path to your site. Where the forged header becomes substantially different can provide clues to where the forger lives. Note that if you receive multiple newsfeeds you may need to repeat this process several times so you can discover all legitimate paths between our site and yours. Once you think you've identified the forger's site, try sending POLITE e-mail to the newsadmin/ sysadmin/postmaster explaining the situation. 5) You issued a cancel control message to a *.test newsgroup. Some users dislike autoresponses for cancel messages, but the newsadmins here think it can be a valuable diagnostic tool for verifying cancel propagation. If you don't like it, use the "delete" key in your mail client! All headers plus at most 10 lines of user text from your original article are reproduced below for your perusal: Path: xpat.postech.ac.kr!news.kreonet.re.kr!insosf1.infonet.net!solaris.cc.vt.edu!news.mathworks.com!zombie.ncsc.mil!news.duke.edu!godot.cc.duq.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!agate!overload.lbl.gov!emf.emf.net!hilbert.dnai.com!nbn!miwok!news.zeitgeist.net!ack.berkeley.edu!not-for-mail Subject: lwall Message-ID: <PINE4545-dhfsdkjc(a)ack.berkeley.edu> NNTP-Posting-Host: ack.berkeley.edu Organization: cypherpunks Lines: 2 From: cypherpunks(a)toad.com Distribution: world Newsgroups: alt.test Date: 6 Feb 1995 19:34:19 GMT test test

1 0

MD5 coding
by philip＠cs.brandeis.edu 17 Dec '03

17 Dec '03

I am looking to put together an MD5 message digest program and have extracted the MD5.c and MD5.h files from PGP(excerpt of the MD5.h file below) but I'm not sure how it all works. Can someone who is familiar with the functions and the data structure please e-mail me with a bit of guidance as to what each one does and how to implement it. If anyone can lead me to a good description of the processes involved I would appreciate that too. Thanks. ----====---- struct MD5Context { uint32 buf[4]; uint32 bits[2]; unsigned char in[64]; }; void MD5Init(struct MD5Context *context); void MD5Update(struct MD5Context *context, unsigned char const *buf, unsigned len); void MD5Final(unsigned char digest[16], struct MD5Context *context); void MD5Transform(uint32 buf[4], uint32 const in[16]); ----====---- Philip Trauring --=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=-- Philip Trauring Brandeis University MB1001 philip(a)cs.brandeis.edu P.O. Box 9110 (617) 736-5282 ['94/95] Waltham, Ma 02254-9110 --=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=--

3 2

RE: Source code for Applied Cryptography
by Johnathan Corgan 17 Dec '03

17 Dec '03

>I think it's been mentioned that the source code for Bruce >Schneier's "Applied Cryptography" was available via ftp. > >Would someone be so kind as to post some locations where it can be >obtained? This web page isn't the complete set, but points to most of it anyway: http://www.openmarket.com/info/cryptography/applied_cryptography.html == Johnathan Corgan "Violence is the last refuge of the incompetent." jcorgan(a)aeinet.com -Isaac Asimov WWW: ftp://ftp.netcom.com/pub/jc/jcorgan/home.html

1 0

Re: Effects of S.314 (Communications Decency Act)
by Michael Sattler 17 Dec '03

17 Dec '03

>Can anyone confirm this S.314 thing? It sounds an awful lot like >the "modem tax" and other urban legends. S 314 IS 104th CONGRESS 1st Session To protect the public from the misuse of the telecommunications network and telecommunications devices and facilities. IN THE SENATE OF THE UNITED STATES February 1 (legislative day, January 30), 1995 Mr. Exon (for himself and Mr. Gorton) introduced the following bill; which was read twice and referred to the Committee on Commerce, Science, and Transportation A BILL To protect the public from the misuse of the telecommunications network and telecommunications devices and facilities. Be it enacted by the Senate and House of Representatives of the United States of America in Congress assembled, SECTION 1. SHORT TITLE. This Act may be cited as the `Communications Decency Act of 1995'. SEC. 2. OBSCENE OR HARASSING USE OF TELECOMMUNICATIONS FACILITIES UNDER THE COMMUNICATIONS ACT OF 1934. (a) Offenses: Section 223 of the Communications Act of 1934 (47 U.S.C. 223) is amended-- (1) in subsection (a)(1)-- (A) by striking out `telephone' in the matter above subparagraph (A) and inserting `telecommunications device'; (B) by striking out `makes any comment, request, suggestion, or proposal' in subparagraph (A) and inserting `makes, transmits, or otherwise makes available any comment, request, suggestion, proposal, image, or other communication'; (C) by striking out subparagraph (B) and inserting the following: `(B) makes a telephone call or utilizes a telecommunications device, whether or not conversation or communications ensues, without disclosing his identity and with intent to annoy, abuse, threaten, or harass any person at the called number or who receives the communication;' and (D) by striking out subparagraph (D) and inserting the following: `(D) makes repeated telephone calls or repeatedly initiates communication with a telecommunications device, during which conversation or communication ensues, solely to harass any person at the called number or who receives the communication; or'; (2) in subsection (a)(2), by striking `telephone facility' and inserting `telecommunications facility'; (3) in subsection (b)(1)-- (A) in subparagraph (A)-- (i) by striking `telephone' and inserting `telecommunications device'; and (ii) inserting `or initiated the communication' and `placed the call', and (B) in subparagraph (B), by striking `telephone facility' and inserting `telecommunications facility'; and (4) in subsection (b)(2)-- (A) in subparagraph (A)-- (i) by striking `by means of telephone, makes' and inserting `by means of telephone or telecommunications device, makes, knowingly transmits, or knowingly makes available'; and (ii) by inserting `or initiated the communication' after `placed the call'; and (B) in subparagraph (B), by striking `telephone facility' and inserting in lieu thereof `telecommunications facility'. (b) Penalties: Section 223 of such Act (47 U.S.C. 223) is amended-- (1) by striking out `$50,000' each place it appears and inserting `$100,000'; and (2) by striking `six months' each place it appears and inserting `2 years'. (c) Prohibition on Provision of Access: Subsection (c)(1) of such section (47 U.S.C. 223(c)) is amended by striking `telephone' and inserting `telecommunications device.' (d) Conforming Amendment: The section heading for such section is amended to read as follows: `obscene or harassing utilization of telecommunications devices and facilities in the district of columbia or in interstate or foreign communications'. SEC. 3. OBSCENE PROGRAMMING ON CABLE TELEVISION. Section 639 of the Communications Act of 1934 (47 U.S.C. 559) is amended by striking `$10,000' and inserting `$100,000'. SEC. 4. BROADCASTING OBSCENE LANGUAGE ON RADIO. Section 1464 of title 18, United States Code, is amended by striking out `$10,000' and inserting `$100,000'. SEC. 5. INTERCEPTION AND DISCLOSURE OF ELECTRONIC COMMUNICATIONS. Section 2511 of title 18, United States Code, is amended-- (1) in paragraph (1)-- (A) by striking `wire, oral, or electronic communication' each place it appears and inserting `wire, oral, electronic, or digital communication', and (B) in the matter designated as `(b)', by striking `oral communication' in the matter above clause (i) and inserting `communication'; and (2) in paragraph (2)(a), by striking `wire or electronic communication service' each place it appears (other than in the second sentence) and inserting `wire, electronic, or digital communication service'. SEC. 6. ADDITIONAL PROHIBITION ON BILLING FOR TOLL-FREE TELEPHONE CALLS. Section 228(c)(6) of the Communications Act of 1934 (47 U.S.C. 228(c)(6)) is amended-- (1) by striking `or' at the end of subparagraph (C); (2) by striking the period at the end of subparagraph (D) and inserting a semicolon and `or'; and (3) by adding at the end thereof the following: `(E) the calling party being assessed, by virtue of being asked to connect or otherwise transfer to a pay-per-call service, a charge for the call.'. SEC. 7. SCRAMBLING OF CABLE CHANNELS FOR NONSUBSCRIBERS. Part IV of title VI of the Communications Act of 1934 (47 U.S.C. 551 et seq.) is amended by adding at the end the following: `SEC. 640. SCRAMBLING OF CABLE CHANNELS FOR NONSUBSCRIBERS. `(a) Requirement: In providing video programming unsuitable for children to any subscriber through a cable system, a cable operator shall fully scramble or otherwise fully block the video and audio portion of each channel carrying such programming so that one not a subscriber does not receive it. `(b) Definition: As used in this section, the term `scramble' means to rearrange the content of the signal of the programming so that the programming cannot be received by persons unauthorized to receive the programming.'. SEC. 8. CABLE OPERATOR REFUSAL TO CARRY CERTAIN PROGRAMS. (a) Public, Educational, and Governmental Channels: Section 611(e) of the Communications Act of 1934 (47 U.S.C. 531(e)) is amended by inserting before the period the following: `, except a cable operator may refuse to transmit any public access program or portion of a public access program which contains obscenity, indecency, or nudity'. (b) Cable Channels for Commercial Use: Section 612(c)(2) of the Communications Act of 1934 (47 U.S.C. 532(c)(2)) is amended by striking `an operator' and inserting `a cable operator may refuse to transmit any leased access program or portion of a leased access program which contains obscenity, indecency, or nudity. -----------------------------------------------------------------------+ Michael Sattler <msattler(a)jungle.com> San Francisco, California | Digital Jungle Consulting Services http://www.jungle.com/msattler/ | | You couldn't get a clue during the clue mating season in | a field full of horny clues if you smeared your body with clue musk | and did the clue mating dance. - Edward Flaherty |

7 13

MIME based remailing commands
by Hal 17 Dec '03

17 Dec '03

From: "Perry E. Metzger" <perry(a)imsi.com> > > I'd say that it would work far better if things were changed to MIME > formats. You would send a message by recursively encapsulating your > message to be remailed inside a MIME message. Simple and clean... Here is an example of how such a mesage might look. I created it using the safe-tcl scripting language. Interestingly, safe-tcl can to a considerable extent be considered a tcl extension to let you work easily with mime messages. It makes it easy to create and parse them. The whole message could be encrypted and marked with the "Encrypted: PGP" header as we do now, or when the new PGP/MIME standard is finalized then that could be followed. I made up two new content types for this, one to hold the composite multipart message, and one to hold the remailer commands themselves. Although these types are not implemented, I think it would be very easy to make a remailer that would use this structure, built out of safe-tcl. (The batching and latency would not be trivial, but the basic remailing would be easy.) Hal > To: hfinney(a)shell.portal.com > Subject: No subject > Mime-Version: 1.0 > Content-Type: multipart/remail; boundary="----- =_792174086" > Content-ID: <1471.792173861.3@cryo> > > ------- =_792174086 > Content-Type: application/remail-commands > Content-ID: <1471.792173861.1@cryo> > > Latency: 2 hours > Minimum-Batch-Size: 5 messages > Anon-Send-To: cypherpunks(a)toad.com > Subject: Example of remailed message > > ------- =_792174086 > Content-Type: text/plain > Content-ID: <1471.792173861.2@cryo> > > This is a message which is being sent to the mailing list. > It is being remailed via a MIME-based structure where two new content types > are defined: multipart/remail and application/remail-commands. The > multipart/remail type is supposed to be composed of two parts, the > application/remail-commands part which has remailer commands, and the > other part which is the "payload" to be remailed. > > ------- =_792174086--

2 1

Re: (dis)advantages of DC-Net vs remailers
by Andrew Lowenstern 17 Dec '03

17 Dec '03

> And when you try to figure how to deal with denial of service > attacks in a big DC net that tries to use bandwidth with tolerable > efficiency -- I don't know if anyone has figured out what would be > involved -- I certainly have not. The bandwidth is the easy part. Building clients that do a DC protocol with real-world reliability and resistance to denial of service is the hard part. And doing all this in a package that would be easy to get people to use is probably the hardest part. The only way I know of to deal with denial of service is for everyone to reveal their flips and kick the attackers out of the net. However, if someone is legitimately transmitting that round they loose their untraceability. So pretty much the only way to do it is ensure that only one participant has permission to transmit and that the participant with permission gets to decide if everyone shows their hands. A way to do this would be to have a separate reservation phase of the protocol. In the reservation phase all of the participants 'bid' on a token. Whoever gets the token has permission to transmit during that round. If collisions have been occurring, the participant holding the token can demand that everyone reveal their flips. I think there is a paper describing a protocol for this, but I don't have access to a library with crypto material. The protocol for distributing the token would be somewhere between an All-Or-Nothing-Disclosure-Of-Secrets and a poker card dealing protocol. Only one person should be able to get the token and nobody should know who got it. To make it more complicated, for people to be able to transmit in a timely fashion, you should be able to specifically request the token when you want it (so you would have a 1/n chance of getting it with n being the total number of participants wanting to transmit that round), and not have any chance of getting it when you don't want to transmit. In addition the generation of the token(s) should be secure so that none of the participants have to trust anyone that only one participant can get a valid transmit token. I can think of a way to do this with a mental poker protocol. The only problem is there is always a 1/n chance of getting the transmit token (where n is the total number of participants), whether you want it or not. I believe it also requires some trust in the 'dealer'... Anyway, the deck would consist of 1 transmit token and n-1 blank tokens. Immediately after the transmit phase the participant holding the token can optionally demand that everyone reveal their flips. To do that the participant would reveal their valid transmit token. At that point everyone else would reveal their blank transmit tokens (to make sure there are no duplicates). If anyone refuses to reveal their blank token, they are removed from the net. Once it's been determined that there is only one valid transmit token, everyone reveals their flips. In theory all of this stuff would work, but implementing it is a different story. For a DC net to be practical, it would have to run completely without human intervention. Maybe a client could be placed in your .login or shell rc file and would run in the background whenever you were logged in. It could keep running after you logged out if you had a message in your queue to be sent out. Clients must be smart enough to synchronize rounds and remove participants who aren't responding fast within time-outs, etc... automatically attempt to 'lay a trap' when collisions have been occurring, figure out who is disrupting or not following protocol and remove them or alternately have the client drop out of the DC-Net when protocol hasn't been followed to satisfaction (duplicate tokens in one round, etc...), etc... Quite a tall order, and for how much more untraceability than the current remailer system? Even if it is implemented you still have to get people to use it. The current remailer system can be used with no software whatsoever... Still, it's an interesting prospect, as it offers real sender and receiver untraceability within the group of participants. But is it worth it? (apologies for the length...) andrew

1 0