December 2003 - cypherpunks-legacy

Just say NYET to censors
by nzook＠math.utexas.edu 17 Dec '03

17 Dec '03

Copyright 1994, Nathan Zook. All rights reserved. Intelectual copyrights pending. NYET-- Non-Youths Exhibit Temperance. Before I start, it may be informative to consider that I consider myself to be a hard-line member of the Christian Conservative movement, and a hard- line advocate of electronic privacy. I am a PhD candidate in mathematics at the University of Texas of Austin, and I got the Electronic Privacy language added to the 1994 Republican Party of Texas platform. I am a member of Trinty Evangelical Free Church, and am twenty-seven years old. As the Internet community continues to grow, the differences of conviction that exists generally in the world find their way into the community. Some demand that newcomers to the net adapt to the mores of this society. Some demand that the net, as a newcomer to the world, adapt to the outside. As recent events have demonstrated, the less reasonable, on both sides, may be endangering the integrity and availablity of the net. Calls for net censorship, it may be expected, will continue to grow unless the net can find some way to police itself. Yet "police itself" is a term that sends the net into fits. My solution, NYET, is for the appropriate users to directly censor the data that they might legitmately lay claim to censoring--data that flows to minors over which they have legal authority and responsibility. Specifically, this is a plan to create two sorts of accounts to the net-- adult and minor. Adult accounts may only be obtained by persons of age eighteen. Minor accounts may only be obtained as adjuncts to adult accounts, refered to as supervisor accounts. Adult accounts would have full access to anything on the net. News readers, telnet, ftp and like software being operated from a minor account would check a file in the adult account to allow access. Newsreaders, in particular, would censor any posts crossed from a non-allowed account. The control files in the supervisory accounts would default to allow-only mode, but could be selected to deny-only. The legal framework that I see important in aiding such a system is as follows: State Level: 1) Declare to hold harmless those BBS operators for charges of Contributing to the Delinquacy of a Minor that obtain and verify the age of account holders, and maintain a NYET system of access for minors. Certain acceptable verification methods specified, with authority to add methods delegated to a regulatory agency. Emphasis to be on ease and speed of verification. Special consideration for in-house systems. 2) Make it illegal to misrepresent age and name data to a BBS. Require BBS operators to maintain a record of age and name of account holders for thirty days after opening of account for hold harmless agreement, and allowing deletion of said data afterwards. 3) Declare aiding in tampering with NYET system to be "Contributing to the Delequency of a Minor". Federal Level: Pass paralell laws for BBSs operating with local numbers from two or more states, or for BBSs operating with 800 numbers. I believe that such a system would protect the full free expression currently enjoyed by the net, while reaffirming parental responsibility in the upbringing of their children. The burden of controlling access devolves all the way to the parents, making charges against BBS operators patently frivolous. Porno charges would then be MUCH more difficult to press, since a jury could be told that specific steps were being taken to prevent access to minors. If parents complained that they didn't want to go to the trouble of spelling out what their children could access, the response is clear: "Oh, so it's not worth the effort to you?" Despite slurs in this group to the contrary, I believe that the proposed us.* heirarchy may well be the first in a series of attempts to censor the net. Remember, we already have had a censor for TV, movies, and radio. It is not really a question of _if_ but _who_ and at _what level_ will this censoring take place. Nathan (Adjusting flame gear)

7 7

Please verify key for remailer@soda
by Jeff Gostin 17 Dec '03

17 Dec '03

Hello fellow C'punks! As my last message said (for those who read it), I'm just getting into anon remailers. I just picked up the docs and PGP key for the remailer@soda. I would appreciate it if people would send me fingerprints of the key. This is so that I know it hasn't been tampered with, or at least can be reasonably sure. Thanx, in advance! --Jeff -- ====== ====== +----------------jgostin(a)eternal.pha.pa.us----------------+ == == | The new, improved, environmentally safe, bigger, better,| == == -= | faster, hypo-allergenic, AND politically correct .sig. | ==== ====== | Now with a new fresh lemon scent! | PGP Key Available +---------------------------------------------------------+

2 1

Re: Remailer ideas (Was: Re: Latency vs. Reordering)
by Jonathan Rochkind 17 Dec '03

17 Dec '03

> Yes, that could be done. Problem is that the NSA's remailer(s) would > immediately deliver messages to the destination. Get enough NSA > remailers, and the web wouldn't be trustable. Now, remailers in the > web can and should feel free to randomly forward mail to other > remailers, but it's the sender who should pick the minimum chain > length, and recursively encrypt their own envelopes. Very good point. Still, I wish there was a way for my local software to automatically make this chain based on some sort of knowledge of what remailers are currently up. Ideally, my local software could figure out all this info without manual intervention on my part; it would maintain it's own list of remailers, and keep track of when they go down. I'm not sure it's possible to set up a system like this, but it would be enormously helpful. One naive solution would be for remailers to have a "ping" function. I could send a remailer a "ping" message, and it would just bounce some acknowledgement back. More likely, my software could do this periodically, and keep track of which remailers are down, or non existent, and not use those. The problem here is that an eavesdropper could get knowledge of which remailers I am planning on using, which could help traffic analysis enormously. The "ping" function could support anon encryption block, so that I can ping a remailer through several other remailers anonymously. This is an improvement, but the traffic generated by lots of people periodically doing this is going to be enormous. As it is in any implementation of this sort. [If you wanted to, you could make the remailers "ping" now by yourslef, just have a message resent to yourself. But we can't all do this automatically often, simply because of the traffic it woudl generate. I think.] The next idea I had involves a usenet newsgroup. Bear in mind I don't really know how this sort of thing works, so tell me when I've said something nit-witted. Anyhow, there could be an alt.remailer.net newsgroup. All participating remailers would post an "i'm here" message on it periodically, say once every 24 hours. This message would include the remailers public key as well. My local software could scan this newsgroup. If a remailer hadn't posted a "i'm here" message in 30 hours or so, my local software wouldn't include it in any chains. If it's been several weeks, my local software will drop it from my database of remailer's altogether. If a "i'm here" from a previously unknown remailer is found, my software adds it to the database. Or, if I'm worried about abuse, I only add it to the database if it's public key is singed by someone I trust. Okay, now everyone try to rip this plan apart. :) I'm sure I haven't arrived at the idea solution, but there's got to be some way to create a remailer-net that will allow my local software to generate long remailer chains to remailers that are all still existent (now, if one of the remailers included in my 6 remailer chain goes down, it's a major pain to figure out which one it was, and why my mail never arrived there), all automatically. Until we can arrive at such a system, remailers are never going to be really useful to a large number of people; it's just too generate secure remaielr ^?chains that are trustable.

5 4

CIA eating internet email & usenet news
by Arsen Ray Arachelian 17 Dec '03

17 Dec '03

It's started. The >CIA< (nevermind that we suspect the NSA has done this already) admitedly is starting an internet site(s) where they will monitor email and usenet feeds. Supposedly this is for "reasearch" purposes where agents would "post" questions in such a way as to not give away their real questions. See this week's Computerworld. Anyone have a scanner they can post this article up with? I'm not up to typing it... =============================================================================== | + ^ + || ' . . . . . . . Ray (Arsen) Arachelian || | \|/ || . . . ' . ' . : . . rarachel(a)photon.poly.edu || |<--+-->||. . . |' '| .' . . ... ___ sunder(a)intercom.com || | /|\ || . . \___/ . . . : .... __[R] || | + v + || . oOOo /o.O\ oOOo :. : .. |A| "And bugs to kill before I sleep"|| =========/---vvvv-------VVVV------------|I|----------------------------------/ / . : . ' : ' |D| This signature pannel is / / The Next Bug to kill(tm) --- now open. / /___________________________________________________________________/

2 2

SpamlessPointer: Internet Shopkeeper
by rah＠shipwright.com 17 Dec '03

17 Dec '03

In the interest of spam-less info citations, please check out the posting in biz.comp.services for "Internet Shopkeeper", which allows people to set up their own internet malls (mini-malls already???), not just buy a shop in someone else's mall. No mention about transaction security in their post, really. I have a copy if anyone misses it. When I get some time, I'll put on my dumpster diving outfit and see what I can find out. If you get there before I do, share all... Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

1 0

Improved remailer reordering
by Hal 17 Dec '03

17 Dec '03

Here is an interesting result I came up with while lying in bed last night. It has to do with the latency/reordering issue. As Eric and others have pointed out, what you want with a remailer is to mix up the messages so you can't link incoming to outgoing one. This implies that you have more than one message to work with, otherwise you don't have anything to mix. And this implies some necessary latency; you have to wait until you have more than one message on hand before sending things out. However, note that latency in itself is generally bad. You shouldn't wait longer than you need to to attain the desired degree of mixing. One simple way this can work is by batching messages up. This could be done by running the remailer at regular intervals, choosing the intervals so that you tend to have enough messages on hand based on average arrival times. But a simpler way is to simply wait until you have N messages on hand, then to promptly mix them up and send them out. This way you have a predictable number of messages to mix each time. Note that in a system like this you might as well send them all out as soon as the Nth message comes in; there is no point in holding on to them for any extra time as it adds latency without improving mixing. The interesting thing I came up with is that there is a simple modification to this batching scheme which gives better mixing with less average latency. To describe it I need some mathematics. One way to measure the benefit of a given degree of message-mixing is by looking at the uncertainty of position of a given message coming in and going out. If we had batches of 4, for example, a given message coming in has its position known with certainty. Going out, it may be any one of four messages, and the probability of it being any one of them is 1/4. A measure that is used for situations like this is entropy. It is defined as the negative of the sum of the product of each probability times its log. (I will use log to the base 2 for the calculations for simplicity.) That is, E = - sum pi * log pi. For the incoming message, we have just {1} as the probability distribution. We know exactly where it is and the probability is 1 that it is there. For the outgoing we have {1/4,1/4,1/4,1/4} as the distribution. It may be any of these four messages with equal probability. Applying the entropy formula to these we get E=0 for the incoming, and E=2 for the outgoing. If we had batches of 8 instead the distribution would have been {1/8,1/8, 1/8,1/8,1/8,1/8,1/8,1/8}, for E=3. Note that entropy is a log measure like the Richter scale. An increase from 2 to 3 is just as big as an increase from 1 to 2. To consider different batching strategies, consider a remailer where the messages come in one per hour, at 1:00, 2:00, 3:00, etc. A four-fold batching strategy would save up messages until there were four, then randomly reshuffle them and send them out. For this case we'd wait until the 4:00 message, then shuffle numbers 1,2,3,4 and send them out, say, at 4:01, in some random order, maybe 2,1,4,3. Then we'd save up more until 8:01 at which time we might send out 7,5,8,6. Note first that there is no point in waiting till after 4:01; once we have the four messages we might as well go. Note too that the average latency for messages in this system is 1.5 hours (the four messages have latencies of 0,1,2 and 3 hours). Four-fold batching produces entropy E of 2 and average latency L of 1.5 hours. Three-fold batching has E=1.58 and L=1; two-fold batching has E=1 and L=.5. Generally, N-fold batching has E=log base 2 of N, L=(N-1)/2. Okay, with this background, we can consider the alternative which gives improvement. It is to have some "rollover" of messages. Instead of sending all of the messages in a batch out, you retain some of them and use them to start the next batch. I call an (M,N) rollover system one which uses batches of M messages but retains N as rollover, sending M-N out each time. By this definition the four-fold latency system above could be called a (4,0) rollover where the 0 means we don't roll any over and send them all out. The simplest rollover case is (2,1). This uses batches of 2 messages, where you choose one at random to send out and keep one. Then when the next message arrives you again choose at random between the new one and the old one, send that out, and keep the other. In the timing example above, suppose we have the message from 1:00. Then at 2:00 when that message arrives, we pick one of the two messages at random and send it out. Suppose it is number 2. We retain number 1 until 3:00. Then we choose at random between 1 and 3. Maybe we pick 1 this time. We keep 3 until 4:00, then choose at random between 3 and 4, and so on. Each message has a 1/2 chance of being sent out immediately, a 1/4 chance of being sent out after 1 hour, a 1/8 chance of going out after 2 hours, a 1/16 chance of going out after 3 hours, and so on. This means that the outgoing probability distribution is {1/2,1/4,1/8,1/16,...}. The entropy of this probability distribution is 1/2+2/4+3/8+4/16+5/32+6/64+... from the formula above, which works out to be 2. The average latency is 0+1/4+2/8+3/16+4/32+5/64+..., which works out to be 1. So, (2,1) rollover batching produces E=2 and L=1. This is the same entropy as (4,0) batching with less average latency. Alternatively, it is more entropy than (3,0) batching with the same average latency. It also has the advantage that you never have to hold more than two messages, compared with three or four for the alternatives. So this scheme has several ad- vantages over simple batching. Now, it does have one disadvantage, which is that there is no upper bound on the latency of a message. With the (4,0) batching you may have had more latency, but you at least know that nothing would have more than 3 message-times. With (2,1) there is a small chance of having very large latencies. In fairness, though, it should be pointed out that in a real system messages arrive at irregular intervals rather than the clockwork model I used above, so even (4,0) would have random latency ceilings. Also, it might be possible to modify (2,1) so that messages never waited more than some maximum number of hours without seriously hurting the entropy. I haven't tried working out the details of other rollover methods, but I suspect that this will be a general method of improving entropy at little cost in latency. In real life we would want large entropies but starting with a (10,0) I'll bet many rollover systems would be superior. Hal

2 1

Re: Children and the Net
by John Young 17 Dec '03

17 Dec '03

Responding to msg by cactus(a)bibliob.slip.netcom.com ("L. Todd Masco") on Tue, 2 Aug 1:5 PM > >Am I the only one that's struck by the similarity >between the propaganda about the Waco massacre and the >propaganda preceding the Persion Gulf massacre? Along with post-massacre spin on the slaughter to teach lasting fear of the killers beyond the event: don't fuck with us, obey or die. Captives an be terrorized into adoration of their captors, whether kids, soldiers or citizens, and propaganda is an uncontrolled munition.

1 0

Re: broadcast encryption
by snyderra＠dunx1.ocs.drexel.edu 17 Dec '03

17 Dec '03

At 3:37 PM 8/3/94, Brian Lane wrote: >and my Linux system. Maybe they'll changes the rules if enough 'new' hams >could get together. I say 'new' because there are alot of old hams who >like things the way they are - they even fought the change in rules that >allow no-code users to get a license without having to take morse code(a >waste of time in my opinion). This may be blasphomey on this list, but I don't have a problem with the restriction on obscuring the meaning of transmissions on the amateur bands. My reading of the rules (and I'd probably double-check with the appropriate persons at the American Radio Relay League before doing so) is that cryptology that doesn't obscure the message, like digital signature, is permitted. After all, the encrypted portion of the message is easily computed or decoded, so its meaning would not be obscured; it just couldn't be generated by anyone else. This could be a solution to a problem I've always had with the digital amateur radio operations: the ease with which someone could be spoof. It's very easy to configure your system to transmit with the callsign of another, or even with a non-existant callsign. This is possible with wired networks as well, but requires access to the machines or cables on the network. With wireless, you can do it from anywhere, and as long as you keep connections short, not get tracked down. With digital signatures, it is possible to authenticate every message, or even better, every packet, and ignore unsigned message/packets. Getting a ham radio license (within the US) is fairly simple. You take a test the questions come from a pool which is public knowledge, pay the volunteer examiners ~$5 to cover the cost of the test(s), and wait for the FCC to send you your 10 year license. No fee for the license itself, and no renewal fee. Given the public nature of amateur traffic, I don't see a problem with the restrictions. There is no such thing as "private communications" on the ham bands. Never has been. If you want such privacy, use one of the commercial bands where it's allowed. Bob -- Bob Snyder N2KGO MIME, RIPEM mail accepted snyderra(a)dunx1.ocs.drexel.edu finger for RIPEM public key When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.

2 1

Ann: PGS v0.99e
by ER CRAMER 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Just another release of Pretty Good PGP Shell: PGS v0.99e is the bug fix for the public beta version of PGS v0.99d. PGS is a very good shell for PGP. PGS has an advanced keyring management system and reads keyring it selves!!! PGS is very easy to use! PGS supports PGP versions 2.3a 2.6MIT 2.6ui. And ViaCrypt PGP versions 2.4 and 2.7. Special requirements: 80286 or up. Changes: A few minor bugs where fixed. The major memory leak in the key information section has been fixed. Because some users did have some problem with PGS changing the color pallet a new color mode has build in that uses standard (STD) colors. It is now possible to save the color mode (PGS, STD (default) or MONO) in the configuration file. PGS v0.99e is available for download at the following sites: Internet: (Right now) wuarchive.wustl.edu:/pub/msdos_uploads/pgs/pgs099ee.zip 128.252.135.4:/pub/msdos_uploads/pgs/pgs099ee.zip (notice that the filename is pgs099eE.zip and not pgs099e.zip, pgs099e.zip was not uploaded correctly). Fidonet: 2:282/317 Request: PGS099E.* 2:280/202 Request: PGS099E.* - -- ... If you outlaw Privacy, only Outlaws will have Privacy! Eelco Cramer <crame001(a)hio.tem.nhl.nl> ------ - -------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLj7UH4DAdPKe9hHLAQFowQP/Qm2AYxxRGBCf8tMFUE5KJGPd97GsXOkZ 9fnG/ofYHkpVgTRNc/jiTWd7502zQdcI95DM0WZoDirnHVjw1Iqxq8HXaxJ9h37X N+d/ClHTfWao9BTXN4FiO0urY/383kFWSlanZYSTQxatHeiIC/9BRVWoIbj8DndX sRMrKVSfrTY= =csjx -----END PGP SIGNATURE-----

1 0

Re: Latency vs. Reordering (Was: Remailer ideas (Was: Re: Latency vs. Reordering))
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <9408051716.AA14773(a)ah.com> Eric Hughes writes: > Back to the start, I guess. > > > Specifically cryptographic elements are easily added to the system > > * packets can be delayed for random intervals > > Let me repeat: > > REORDERING IS OF PRIMARY IMPORTANCE FOR REMAILER SECURITY. > > ADDING LATENCY IS NOT. No need to shout, we heard you the first time. ;-) In a system that is carrying continuous traffic, random packet delay is functionally identical to packet reordering. If messages are fragmented, random delays on sending packets out is functionally identical to reordering. More importantly, RemailerNet as described defeats traffic analysis by more significant techniques than reordering. Reordering is a weak technique. The introduction of noise, 'MIRV'ing of messages, fragmentation of messages, random choice of packet routes, and encyphering of all traffic are stronger techniques. -- Jim Dixon -- +-----------------------------------+--------------------------------------+ | Jim Dixon<jdd(a)aiki.demon.co.uk> | Compuserve: 100114,1027 | |AIKI Parallel Systems Ltd + parallel processing hardware & software design| | voice +44 272 291 316 | fax +44 272 272 015 | +-----------------------------------+--------------------------------------+

4 4