December 2003 - cypherpunks-legacy

Latency vs. Reordering
by hughes＠ah.com 17 Dec '03

17 Dec '03

This horse isn't dead yet. The distinction between latency and reordering is if primary importance to the cryptanalysis of a remailer network. To repeat yet again: reordering provides security and latency is a by-product of reordering. I assert that anyone who's given a modicum of thought about how to cryptanalyze a remailer network understands this distinction well. I also assert that those who haven't thought about cryptanalysis don't understand the distinction, even if they do believe in it by authority. One of the oldest maxims in the book is "Don't design ciphers until you've tried to break some." A remailer network is intended to be a cryptographic object, a new kind of cipher. I assert that if you don't understand the distinction between reordering and latency, you've not thought enough about the cryptanalysis of remailers and shouldn't be designing them. Therefore, in the future, from here on out, I will label the promoters of latency as "sellers of snake oil." It's the same fallacy as creating a new cipher by putting lots of complicated operations inside it without understanding where the security comes from. Eric

1 0

Clipper in the Commics
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Well, I guess this is about as mainstream as the issue can get. In today's paper, the comic strip "On the Fast Track" is about the clipper chip. It suggests that we need a way to spy on government in return (other than by bribery). To say that I was surprised to see a clipper statement in the 'toons would be an understatement. Looks like our campaign to inform the public is paying off. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLkKPYVVkk3dax7hlAQEg9AP5AXe5mr++9Af3QCcyozIKqKqp5FXadKqG Eaj+2An+loxXafaqNVwuKoZJMemA68yRYKguIZKjk6kQPhw3zp5D1h6Ynj3OoUvI AhPHHnDBiA+ehz5FSZfQESdRJtjM+6qQ/vcbgnSBeFvEEYi4531Q9t36pQJcWB8X n2Jlr6U3jjE= =BVHe -----END PGP SIGNATURE----- -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.3 key available by finger or server. "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

1 0

email packet length size
by hughes＠ah.com 17 Dec '03

17 Dec '03

Message length quantization is necessary for security in a remailer network. Right now there's not enough traffic through the remailers to warrant more than one such quantized length. What length should that be? This information can be readily calculated from the length distribution of the current messages passing through the remailers. If only one or two remailers would instrument their devices in order to record just lengths, that would provide the necessary data. Any volunteers? My complete guess is that it's going to be around 4-5 KB. Eric

1 0

Problem in draft FIPS `CRYPTOGRAPHIC SERVICE CALLS'
by M.Gream＠uts.EDU.AU 17 Dec '03

17 Dec '03

Anyone producing cryptographic software elements should take notice of the recent FIPS draft standard on `cryptographic service calls' dated 23 May 1994. It attempts to define data structures and "function" calls towards the goal of making better interoperability between applications and crypto "libraries". However, you'll notice that both DSA and RSA modulus sizes are constrained to a `MODULUS_SIZE ' of 64 `BYTE's (unsigned char). This permissible maximum of 512 bits is too small, and a violation of FIPS-186 s.4.1. amongst others. I like this FIPS, but it would be pretty useless if it contained the above restriction. If you're also a software developer, make a comment to NIST on the issue, so they do change it. Matthew. -- Matthew Gream <M.Gream(a)uts.edu.au> -- Consent Technologies, (02) 821-2043 Disclaimer: From? \nem speaking_for(Organization?)

1 0

Re: RemailerNet
by Jonathan Rochkind 17 Dec '03

17 Dec '03

Part of our disagreement/misunderstanding might be in differing conceptions of the form the remailer net should take. > There should be two anonymous IDs, one for sending, one for > receiving. You seem to be talking about a Julf-style anon system, where the system knows who you really are. If the system is corrupt, if Julf were an NSA agent, then the entire system is compromised and useless. I like the cypherpunks remailer concept better, where each link in the chain only knows the next link in the chain, and security is achieved by multiple links. If several of the links are actually NSA agents, your security is reduced, but not compromised completely. If you've got a chain of, say 10 links, even if 7 of them are evil NSA agents, you still can probably retain your anonymity. Return addresses are accomplished by encrypted "resend-to:" blocks. It seems much preferable to have a system where it isn't neccesary to trust any one net entity completely, as it is in a Julf-style anon-ID system. [Of course one could use a combination of both in communications too, but I wouldn't feel safe unless my anonimity was safe even if the Finish FBI raided Julf's site.] When looked at with this goal in mind, I think maybe the newsgroup as a method of passing remailer net information makes a bit more sense. I don't think the possibility of the newsgroup being spoofed is actually fatal to the system. Let's examine ways in which it could be attacked: 1) The Enemy could introduce completely made-up "i'm here" messages, pointing to non-existent remailers. This doesn't harm anything at all when combined with a "ping"ing of remailer sites, as I've suggested. (One idea would be just to periodically mail all your remailers with the resend-to: being yourself, to make sure they exist, and are forwarding mail at least some of the time). 2) The Enemy could announce his own Evil-remailers to the net. These remailers would in fact exist, but would do evil things designed to compromise the net. What could they do? They could publicize all messages they get. Again, as long as you have 3 or 4 non-evil remailers in your chain, this doesn't really compromise your anonymity. You can decrease the risk further by only using remailers whose announced keys were signed by a trusted source. The evil-remailer could also just drop all communications in the bit bucket. This doesn't compromise security, but does make the remailer net unusable. By periodically pinging the remailer sites as I've suggested above, this risk can be minimized. If you've pinged the site 25 times, and all 25 times the remailer has forwarded your ping back to you, then odds are that it isn't dropping any messages in the bitbucket. (remember, the evil-remailer can't tell the difference between your ping a a normal remailer message, if done correctly.) 3) The Enemy could intercept announcement messages from good remailers, and replace their public key with his own. He could then intercept all mail to this good remailer, and read it, and forward it on, or drop it in the bitbucket. Using web-of-trust for signed remailer keys should help minimize this risk. 4) Denial of service: The enemy could intercept the announcement messages, and keep them from getting to the newsgroup. This doesn't compromise the security of the net at all, but is annoying. I can't think of any way to avoid this risk, but I think it might be acceptable, because it doesn't actually compromise any security, and would be fairly dificult for the enemy to do for long without being detected. 5) The enemy could intercept announcement messages from good remailers, and replace both the public key and address with his own. This is really just a combination of several of the previous attacks, nothing new.

2 1

Encryption (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Received this in the mail today. --Mike Forwarded message:

1 0

Re: Voluntary Governments?
by dance＠cicero.spc.uchicago.edu 17 Dec '03

17 Dec '03

[JWS writes:] >Well, yeah. And this is a service. When individuals exercise their >freedoms, they frequently interfere with other people's freedoms. To >resolve this conflict, it is necessary to "control the actions or the >behavior of" individuals such that they don't interfere with each >other's freedoms. So they enter into a contract with each other >under which this is accomplished, but a contract isn't worth the paper >its written on unless somebody enforces it, so they hire a policing agency, >the government. That agency is providing a useful service. Well, as a tribalist, I don't agree that this "useful service" is ultimately necessary. I *do* agree, however, that government is necessary *at the moment.* As a species we have not evolved enough to learn to take personal responsibility for our actions, therefore an external restraint system is necessary. My particular slant on anarchy calls for personal responsibility, which I believe renders an external system of superintendence unnecessary. But as I said before, this species isn't ready. >> It would be great if government could be a service provider, or simply feel >> responsible for those it governs--but then it would not be a government any >> longer. > >I don't agree with that last clause. I would rather have Customer Service than government, but I don't believe I can have both. Write me some more and hear my other stupid ideas. ;) _/_/_/ _/_/_/ _/_/_/ _/ _/ The ancients who wished to _/ _/ _/ _/ _/_/ _/ illustrate illustrious virtue _/_/_/ _/ _/ _/_/_/ _/ _/ _/ throughout the world first _/ _/ _/ _/ _/_/_/_/ _/ ordered well their states. _/_/_/ _/_/_/ _/_/_/ _/ _/ _/_/_/ Wishing to order well their states, they _/ first regulated their families. Wishing to regulate their families, they first cultivated their persons. Wishing to cultivate their persons, they first rectified their minds.... --THE GREAT LEARNING (Text & Commentary, IX)

1 0

RemailerNet
by Jim Dixon 17 Dec '03

17 Dec '03

In message <199408042200.SAA07928(a)cs.oberlin.edu> Jonathan Rochkind writes: > > * Rochkind's stability-from-being-paid and web-of-trust notions > > I'm not sure I like being credited with the "stability from being paid" > notion. I think there _is_ stability from being paid, but I think > if the infrastructure depends on it, it's not a good infrastructure. If you look at the history of the Internet, there have been some free Internet services, but the ones that have thrived have been paid. (If the government or your school subsidizes your Internet access, it may appear free to you, but the staff all get their paychecks every month. > The system should be able to create a stable top-level infrastructure > on top of an inherently instable environment, with remailers > going up and down, and popping into existence, and dying. It should > route around dead remailers, like the internet itself. If it is built like the Internet, it will do just that. > > 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. > > It _would_ make it easier to spoof the system, but I think it does add > several very important things: > 1) New remailers can easily announce themselves to the remailernet. > [Whether they are to be trusted or not should depend on pgp-signed keys > and web of trust, but the newsgroup provides an way to announce yourself > to the system, and have that announcment by automatically dealt with > by all participating parties] There are two things being blurred together here which should be kept distinct. The first is gateway-to-gateway announcements. The second is advertising of the RemailerNet gateways to the wider world. Generally I would expect gateways to introduce themselves to one another privately and negotiate an understanding. Part of this will normally take place off the Net. This is an infrequent event, and so can be time-consuming and expensive. The basic web of trust is that between gateways. Once gateways had entered into a relationship, there would be frequent encrypted private traffic between them which would maintain the trust. Gateways can also announce their presence to the wider world, and publish their public keys. This could be done in alt.RemailerNet or it could be done in alt.internet.services, or any of several other places, or all of these. Any information published in alt.RemailerNet would be suspect, because it could be a complete fabrication or it could be a modified version of the correct posting. Gateways could be started up by anyone and some postings to alt.RemailerNet would be spurious. The "gateway" could be a sink, just tossing traffic sent to it, or it could copy all messages to a TLA before forwarding them. The user-gateway web of trust would therefore be far more problematical. I think that this would function as a market, and unreliable and untrustworthy gateways would be driven out over time. At the same time, there would be a constant bubbling up of new remailer networks, because the software would be freely available and the protocols well defined. The longer lasting gateways that proved trustworthy would in time join established networks. > 2) Users (not people operating remailers, people using them) could make > use of the newsgroup, to compile a database of remailers, and make long > remailer chains. Users could have automated software doing this. Compiling a list of remailers, sure. But if you let the user control how messages are chained, you are inviting real traffic analysis. The user should only be able to specify his destination and the level of security desired. > [snip] > These are really two facets of the one problem, of allowing a user > or remailer who has just arrived on the seen to quickly get a list > of remailers, and make use of them, all automatically. That's sort of the > super-set problem which encompasses the other two, and whose solution solves > the other two. > > I don't think it's a coincidence that the newsgroup system solves these > two problems at the expense of security (the newsgroup makes it easier > to spoof). If the newsgroup is used as described above, RemailerNet itself is not threatened; it is only the users that can be spoofed. This level of risk is unavoidable. But gateways would never use the newsgroup for inter-gateway communications, because (a) it would be redundant (they can talk directly once they know each other and (b) you would have to assume that anything posted to a newsgroup had been compromised. > The fact is, that even remailers exchanging mail _can_ be spoofed, if not > quite as easily as the newsgroup idea. It seems to be a premise of cryptographic > protocols and schemes, that you've got to assume a worst case and get a system > working where even under the worst case, everything works. Well ... if you follow this line of reasoning too far, you are just saying 'nothing can be trusted, so don't bother being careful'. If I were running a remailer and someone posted his address in a public newsgroup and said "hey, here I am, and I run a really good remailer" I wouldn't trust him just because he signed it. I would get in touch with him, ask around about him, maybe run some low-security traffic through his remailer for a while. Then after some time I would raise my estimate of his trustworthyness. If he dropped traffic, if someone reported that something that they had sent privately had been compromised, I would drop him. > I agree that it seems a good idea for the SMTP RFCs to be used to exchnage > info, ... etc You already use the SMTP RFCs to exchange information -- this message comes to you courtesy of those RFCs. Email can have very complex headers and they can be in pretty much any order. This makes it difficult to write email software. I am simply suggesting that we allow only the minimal few headers, with possibly a few added to support RemailerNet protocols. ASSIGNMENT OF ANONYMOUS IDs These types of traffic are possible, where 'known' means your ordinary email address: known --> known known --> anon anon --> known anon --> anon There should be two anonymous IDs, one for sending, one for receiving. I assume that anonymous IDs are never assigned automatically. If you want an anonymous ID pair, you ask the gateway for one, possibly enclosing your public key encrypted with the gateway's public key. The gateway returns your new IDs, encrypted if you you gave it a key. The 'send' anonymous ID is used for sending messages from someone else's account. The gateway converts it into a 'receive' ID before forwarding your message. The 'receive' ID appears on your email after it goes through the gateway and can also be passed to other parties who want to send you remailed messages. Additional security can be added by using a digital signature. The gateway could be instructed ignore messages lacking such a signature or to take some specified action. ELECTRONIC CASH Ecash is easily added to such a system. 'Emints' would generate a message containing a bank identifier and an encrypted value. This would be the ecash. It could be given to anyone or anything. Messages containing ecash would be encrypted. The emint would credit the account of the first person to present it, and would bounce any copies presented subsequently. Giving change would be trivial. -- Jim Dixon

2 1

Mea Culpa; email blunder
by corpuz＠internex.net 17 Dec '03

17 Dec '03

I accidentally hit the send again function instead of the delete function on an email file that I was processing. No need to respond -- I am apolitical, didn't even read it, and don't care what it said -- and I will try not to bother you in the future. Again, sorry for any inconvenience.

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