December 2003 - cypherpunks-legacy

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

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

17 Dec '03

The problem of designing a reliable and trusted remailer network is a generalization of the problem of constructing a reliable Internet and so many of the solutions can be the same. The structure of the Internet has been gone over and over again for twenty years or so and is probably optimal. This suggests that * all packets should be acknowledged * messages should be broken down into packets which are routed independently * users should communicate with trusted gateways * users should be accessible through a hierarchy of logical names which includes the gateway name * gateways should be known to users only through their logical names * the gateways should frequently exchange routing information * that routing information should have an expiry date * gateway operators can choose who they announce routing information to and accept routing information from * users may have accounts with gateways and be charged for gateway usage * gateway operators can settle accounts between each other periodically * system software should be obtained [only] from trusted sites; to make things simpler, it should be possible to distribute bootstrap diskettes that allowed the bulk of the software to be downloaded or updated over the net without being compromised Specifically cryptographic elements are easily added to the system * all inter-gateway traffic should be encoded * packets can be delayed for random intervals * routing of packets can be somewhat stochastic; that is, you don't generally packets by the quickest route, and the choice of forwarding gateway is not 100% predicatable, given the destination gateway * packets can be fragmented and padded with noise at random * noise packets can be added at random * route selection, packet fragmentation, and noise generation can be continuously adjusted to defeat traffic analysis The following suggestions raised in recent postings are included in this scheme: * cjl's MIRV capability (except that it is supplied by the system and not the user) * Jidan's noise injection * Rochkind's stability-from-being-paid and web-of-trust notions * Markowitz's automated contacts between mailers * a form of digital postage * Rochkind's pinging The following are very easily supported by the scheme: * a form of digital cash (the gateway operator would run a tab for users, like a credit card company) * digital signatures * message transfer via custom Internet protocols as well as via the email system * users could specify the degree of confidentiality required and the system would use stronger encryption, increase chaff (anti-traffic analysis measures), and restrict use to more trusted gateways as required Where email is used to transfer messages, the format used should be a subset of that specified in the SMTP RFCs. Restricting the structure of the headers would simplify the remailer software at little cost to the user. The use of alt.x groups to exchange gateway information does not seem to add anything to this system; in fact it would seem to make it easier to spoof the system. There could be multiple remailer nets, some commercial (paid for) and some free. The commercial networks could choose to exchange traffic with the free networks at no charge. Commercial remailers would probably be very concerned with legal issues, both criminal (pornography, etc) and non-criminal (copyright violations). -- Jim Dixon

8 13

Remailer stuff
by greg＠ideath.goldenbear.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Sorry if I'm being dense - will someone please E-mail me and tell me why outgoing-only (or incoming-address-unavailable) remailers are useful? Also, with respect to getting the addresses of working remailers from a newsgroup - it may not be a good idea to treat any address advertising itself as a remailer as a useful remailer. Remailer 'x' may well be run by a remailer-hater who publishes its traffic openly, archives it for sale to the highest bidder, is a front for the NSA, etc. I'm only inclined to trust remailers run by people I trust; or maybe those with keys signed by "C-punx Remailer Certifying Service". It's important to let the user have some degree of control over which remailers are used. (The newsgroup does seem like a nice way for remailers to indicate they're still active, though.) Are people really interested enough in more advanced measures to protect privacy that they're willing to pay for them? The digital-postage remailer stuff sounds interesting to me - but I have a hard time believing that people will pay (and go through extra hassle) to get the same functionality they already get with existing remailers. I've also considered setting up a privacy-friendly Internet site; I believe that Sameer Parekh has already done so. I don't remember seeing anyone but Sameer post from his site, however. I don't mention this to slam Sameer but to point out that perhaps people aren't interested enough in privacy to want to go to much extra trouble to get it. (Of course, everyone posting to the list now is already known as a list member - switching to a privacy site wouldn't add much.) I agree that it would be nice to have privacy-friendly Internet access available - I agree strongly enough that I'm willing to work towards providing it - but I'm reluctant to commit hundreds of dollars per month to set up a site that won't attract enough business to even be self-supporting. Would it be worth $5 or $10 per month to folks to have a mailbox they used via IMAP or POP, or $20 or so for a shell account on a box at the end of a 56K feed? (I don't see C-punks as a very big fraction of the customers of such a site, but I'm surprised that there doesn't seem to be more interest in practical privacy stuff.) -----BEGIN PGP SIGNATURE----- Version: 2.5 iQCVAgUBLkChoH3YhjZY3fMNAQFVvQP/b2g8rgUaxWkdBR34DqMfR6T8bDZOhDmo gATzHduPlbFTWsz2BV6ME/XgHJAxJAT14kZx8vTEKy/y3PgR7tg4zz0pcj+shZWB BZlatH8EpZNffxO+yBF0B9Ur7HC7QrwixhVu7LjFmDwgKEnpRF/w54K8I0eXTfEh PpMXeFvVKkw= =T9pL -----END PGP SIGNATURE-----

3 2