December 2003 - cypherpunks-legacy

RE: (none)
by Jeff Gostin 17 Dec '03

17 Dec '03

Blanc Weber <blancw(a)microsoft.com> writes: > I really meant to ask 'where cypherpunks'. It had been a whole day & > more without the hordes messages and my day seemed empty, without code > or purpose, lacking controversy & jibber jabber. Actually, my response was more of a joke... More than a few people commented on the fact that WHO CYPHERPUNKS is the 'domo command to get a list of subscribers. Your name looked familiar from the list, so I decided to gamble a joke. Guess the joke's on me, eh? :-) --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 +---------------------------------------------------------+

1 0

Re: RemailerNet
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <9408062108.AA18761(a)snark.imsi.com> perry(a)imsi.com writes: > > Jim Dixon says: > > You can send from a very large network and forge your TCP/IP or > > (more difficult) Ethernet source address. But I can sit on the same > > network, build a table relating TCP/IP to ethernet (or whatever) > > addresses, and filter out messages that should not be there. There > > are commerical packages that do this sort of thing. > > Huh? > > If you are sitting on a network in England, which you appear to be, I > defy you to record anything at all about the ethernet addresses of the > machines that originated this message. [etc] Forgive my casual use of the English language. "A may send from a very large network and forge his or her TCP/IP or Ethernet source address. But if B is on the same network, he or she can build a table ..." The size of the source network is related to the difficulty of determining which machine is forging addresses. If you are ... sorry, one is on a large network, forgery without detection is much easier. Assuming idiocy on the part of correspondents may make for easy and fast responses, but it injects an undue amount of noise. -- Jim Dixon

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 <9408070005.AA17290(a)ah.com> Eric Hughes writes: > In a system that is carrying continuous traffic, random packet delay > is functionally identical to packet reordering. > > OK. Prove it. Here are some difficulties I expect you'll find along > the way. > > First, "continuous traffic" is the wrong assumption; some sort of > multiple Poisson distribution for arrival times is. Sigh. I say "A implies B". You say, "not A, and so proposition is incorrect". In elementary logic, you are wrong. IF the traffic is continuous, THEN random delays introduce reordering. The proposition is completely obvious. Do I really have to spell out a trivial proof? > This is by no > means a hypothetical. The backoff algorithms for TCP had to be > developed because packet streams are not continuous, but bursty. Under this modified assumption, you must remember that I proposed that noise packets be introduced to defeat traffic analysis. The bursts will be smoothed out. Not perfectly. Many of the characteristics of TCP/IP derive from its design being optimized for speed. RemailerNet would give less importance to speed, and more importance to opaqueness to traffic analysis. [snip] > Fourth, the problem is incompletely specified, since the distribution > of random added latencies is not made specific. Correct. You assume details that have not been specified, and then critique them at length. > If messages are fragmented, random delays on sending packets out is > functionally identical to reordering. > > This is false; a system that concentrates on reordering has provably > better average latency that one based only on adding latencies. If a message is fragmented into N packets, and then the dispatch time slot for each packet is assigned randomly, the packets are reordered. [Comments deleted ignore the fact that messages are fragmented, and so are irrelevant.] His arguments also ignore the fact that reordering messages of different lengths is useless as a defense against traffic analysis, suggesting that this is polemic rather than a serious argument. > More importantly, RemailerNet as described defeats traffic analysis by > more significant techniques than reordering. Reordering is a weak > technique. > > WHAT?? > > Anyone else listening to this: I believe the above quoted two > sentences to be distilled snake oil. I say again: reordering is not weak, it is irrelevant if messages are of signficantly different lengths and are not fragmented. > The introduction of noise, 'MIRV'ing of messages, > fragmentation of messages, random choice of packet routes, and > encyphering of all traffic are stronger techniques. > > Encyphering is necessary. Reordering of quanta is necessary. > > "MIRV" messages may actually decrease security; multiple routes may > decrease security; fragmentation may decrease security. Noise > messages may not be resource effective. > All the above claims require > some justification, and I have seen nothing robust yet. If by "the above claims" you mean the preceding two sentences, I do agree. -- +-----------------------------------+--------------------------------------+ | 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 | +-----------------------------------+--------------------------------------+

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 <199408070216.TAA09025(a)jobe.shell.portal.com> Hal writes: > This suggests, that IF YOU COULD TRUST IT, a single remailer would be just > as good as a whole net. Imagine that God offers to run a remailer. It > batches messages up and every few hours it shuffles all the outstanding > messages and sends them out. It seems to me that this remailer provides > all the security that a whole network of remailers would. > > If this idea seems valid, it suggests that the real worth of a network of > remailers is to try to assure that there are at least some honest ones > in your path. It's not to add security in terms of message mixing; a > single remailer seems to really provide all that you need. Yes, in an ideal world. Each additional remailer introduces another chance of being compromised. But in an ideal remailer network operated by real human beings, you cannot trust the operator. You would prefer that at least the points of entry and exit from the network be different, because this decreases the probability of the message being 'outed' by a very large factor. If you are seriously concerned about legal factors, you would prefer that the remailer gateways be in different legal jurisdictions. However, if you trust the operator and if this trust is guaranteed to be continued forever, the ideal number of remailers is one. -- Jim Dixon

3 2

remailer ideas
by Jonathan Rochkind 17 Dec '03

17 Dec '03

My newsgroup-RemailerNet ideas seem to be getting mixed reviews, but I think that part of the p roblem is that some people don't understand what I'm trying to accomplish. There are several features I think are extremely desirable in a remailernet infrastructure, which our current infrastructure doesn't accomplish, and which no proposed infrastructure that I've seen accomplishes either. I'm not certain my newsgroup/pinging idea addresses these concerns, either, but I'm going to lay them all out, and y'all can see what you think. These points aren't distinct, I realize. They're all interrelated somewhat. 1) New remailers should be able to enter the "remailernet" easily, and with a minimum of human intervention. If I decide to run a remailer, the infrastructure should provide a way to make it visible to all other particpants in the remailer net, other remailers and users. Whether the other participants make use of it or not, is another question, and would presumably depend on a web-of-trust kind of situation. But currently, someone who wants to stay current with this kind of info basically has to read cypherpunks, and take notes when people announce new remailers. Better, would be if this sort of "new remailer" info could be distributed automatically, to both users and other remailers. 2) Remailers should be able to leave the remailernet without devestating it. If my remailer is temporarily, or permanently, down, the remailernet should route around it. Again, the current way for operators to announce this would basically be to post to cypherpunks list, and maybe alt.security.pgp too. If other remailernet particpants miss the announcement, havok can ensue. If a middle link of your remailer chain is down, all you know is your messages aren't getting to their destination, you won't know which link is down. We shouldn't require all particpants to read cypherpunks religiously, and if an operator isnt' conscientious enough to post to the expected places, it shouldn't be fatal. Both users and remailers should have an automatic way of finding out about down remailers. 3) Remailers themselves should have a way of automatically learning the topography of the remailernet. If we want to form a cohesive black-box remailernet, remailers are going to need this info. Maybe they're sending fake padding between themselves to thwart traffic analysis. Maybe they're encrypting with the key of the next remailer down the line automatically for you. I don't know enough about it to know what methods are best, but it seems probable from discussion that remailers are going to need to do something that requires knowing about all the other remailers, and their PGP keys and such. 4) Users should have a way of learning the topography of the remailernet too. A way which doesn't require so much human intervention. I should be able to tell my software "send an anon message to X, put 10 links in the remailer chain," and it will do it. To use the remailer net, I shouldn't need to read cypherpunks in order to keep track of all various remailers, and which are up, and which are down. My software should do that for me. And again, your software doesn't need to use all the remailers that it knows about, it can rely on web-of-trust based on PGP signatures and such. [Although I'm not certain this is neccesary, as I've come to the same conclusion as Hal Finney: as long as you've got one (or maybe two) trustworthy remailers in the chain, you are pretty much okay. Although Jim Dixon points out that a concerted effort by the TLAs could make even finding one trustworthy remailer a serious chore. But this is an implementation problem; we're talking theory here at the moment.] 5) No one entity participating in the remailer net structure should be able to compromise the security of the net acting alone. For example, An "evil remai ler" operating solely for the purpose of compromising the remailernet shouldn't be fatal. This is a matter of degree to some extent: if everyone but you is "evil", you're going to be out of luck in just about any system. But the more robust the infrastructure is, the more evil participants it can handle before it cracks, the better. The current remailer net actually fulfills this requirement fairly well, but it's an important one, and worth noting anyhow. Now I think the infrastructure I've proposed that uses a newsgroup, as well as a pinging mechanism, fulfills all these requirements. But I'm not going to try to defend it now, instead, what do you all think about those requirements? Are they all in fact neccesary? Or desirable? Are there any more that should be added? Can you think of any infrastructure systems that might fill some or all of them?

1 0

Latest mention in Wired
by Al Billings 17 Dec '03

17 Dec '03

I noticed in the Sat Pirate article in the latest Wired (which I finally read this evening), there is a mention of the Cypherpunks in connection to PGP and opposition to the creation of a Police State. Page 128, I think. -- Al Billings mimir(a)io.com http://io.com/user/mimir/asatru.html Nerd-Alberich Admin for Troth - The Asatru E-mail List Lord of the Nerd-Alfar Sysop of The Sacred Grove - (206)322-5450 Poetic-Terrorist Lodge-Master, Friends of Loki Society

2 2

Re: e$: Cypherpunks Sell Concepts
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 8:20 AM 8/7/94 -0400, Perry E. Metzger wrote: >It is perfectly feasable to track all financial transactions in the >U.S., down to the "quarter for a phone call" level, without >eliminating all capacity to use the data or placing more than, say, >another several percent burden on the cost of all transactions. I know >how to architect such a system, and I'm sure that I'm not the only >one. It would be a big job, but not an impossible one, especially not >with modern computer systems. A several percent burden on the economy >would be devistating, but from the point of view of the bureaucrats it >probably isn't such a bad thing. Ahh. Perry to the rescue. This is even better than being technologically impossible. Economic impossibility is *just* as physical (I cite the failure of command economies like the USSR and Cuba as my evidence) as is technology, and since we're looking for a business case here, your reply comes in at the nick of time. One more point for regulatory arbitrage. That "several percent" deducted from the gross domestic product of a nation could tip the balance of it's international competitiveness, and could forgo that country's requirement for trapdoor ecash. The threat of that could be enough to shoot down the idea on this side of the American border. Parkinson's law holds that organizations like bureaucracies tend to expand to use all their available resourcess. But it's a law of biology that a parasite doesn't kill its host. Does your Forbin project above include the ability to store and retrieve *all* transactions down to a quarter phonecall permanently? ObThreadPlug: Here's my panel categories for the afternoon "where do we go" session: Chair: Famous Software/Biz Heavy or TechnoVisionary 1. Internet access provider, 2. Underwriter, 3. Financial Operations Person, 4. Regulator or Lawyer, 5. Politician. Any other ideas?? 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

Re: e$: Cypherpunks Sell Concepts
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 8:24 AM 8/7/94 -0400, Perry E. Metzger wrote: >Robert, you don't understand. The U.S. is not governed by laws any >more. In the financial community, every action you perform is illegal. >The only way that you stay out of jail is by being nice to the >bureaucrats. This reminds me of my criminology class in college. The prof's main point was that there is no crime, particularly organized crime. It is all just illegal business. There was some research done in Seattle in the early 60's. The researchers discovered that practically every business could be found to be breaking a serious law in Seattle's byzantine city code. Vending machines were illegal, for instance. This allowed cops to shake down anyone they pleased. It also allowed a sizable criminal class to exist, because those people just paid the cops and went about their business. There was reason to believe that all this was done on purpose to enhance the income of various politicians at the top of the payoff tree. Of course, vending machines were everywhere, particularly in cash-based businesses like resturaunts and bars. This could be extended to people in the main business district as well. Their "fees" may not be so much outright bribes, but campaign contributions, "donations" to a politician's favorite charity or civic event, investments in a politician's business activities, and of course, taxes. >They allow money market funds, even though they >technically violate a dozen laws, because they feel like it. They >could prohibit them if they felt like it, too. The bureaucrats aren't >going to want digicash, so they are going to find plenty of excuses to >prohibit it. You can't do legal hacks in an environment like this. It >doesn't work. If the bureaucrats don't like you, they shut you down, >and there is not a damn thing you can do about it, period. Democracy is in fact mob rule, with various Robbespierres guillotining people to keep the crowd happy. Michael Milken was one of those people who got it in the neck, not so much because what he did was wrong (it was) in the eyes of the people who pulled him down, but because he was too good at what he did and thought he could ignore the crowd. Hubris. So, we have to include Mme LaFarge in our thinking. I believe that legal hacks are necessary, but not sufficient. The economic necessity of ecash, the business case, has to be demonstrated. We can't really know whether it will work unless it's tried. We can't really do that until the "civic authorities" let us put up the vending machines. To do that, we need to be able to incent their cooperation. The possibility of profit furthers that discussion enormously. If regulatory agencies can be convinced to allow non-bank banking ala Fidelity, and a multi-billion dollar industry can result, than it might be possible to allow a non-treasury currency (with proper controls of money supply, to keep Uncle Miltie happy) on the promise of another multi-billion dollar industry. In the above quote you're assuming that they aren't going to want ecash, that they won't find plenty of excuses to allow it. The point is, we have to make the bureaucrats *like* us. The best way to get that to happen is to talk about the business e$ could create. It is a proven fact that sizable proportions of regulatory officials leave their agencies for jobs in the markets they regulate. If there's to be a market on the other side of that revolving door, they have to help us out a little. It was ever thus. Columbus did it. Brahe did it. Oppenheimer did it. Friedman did it with the Chicago Mercantile Exchange. Hell, even Lysenko did it and made it stick for 50 years even when the science was bogus. Fortunately, we don't have our dear comrade, the "Man of Steel", to back us up. > >True, you can leave the country and do your business there -- I know >several hedge funds that already refuse to take any customers from the >U.S. because they don't want the headaches, and there are other >similar things happening in lots of other parts of the financial >industry. However, don't think you can finesse the folks at the Fed, >the IRS, the Treasury, and the SEC -- they are monsters, and they >won't be stopped by the courts. Ever since I've been old enough to understand English, I've heard the various libertarians and ultraconservatives in my family say that they had Seen the Golden Age of America and It's Over Now. I have no idea if they, or you, are right about that. (Not to call you either of those political labels, I know better.) The Roman Empire mutated into the Holy Roman Empire (can you say "Byzantine"?, I knew ya could) and lasted another 1000 years before it was sacked by the Turks in the 1400's. People did business in Constantinople the day the place burned; they were doing business there the day after it burned. If there's a market, there'll be a business. If there's a business there'll be excess money (profits). If there's excess money, there'll be politicians, elected or otherwise. However, it's a stupid parasite which kills it's host, and that's what I'm counting on here. Cheers, Bob Hettinga ObThreadRelevance: Anyone have speaker/demo ideas for the morning "intro to e$" session? ----------------- 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

Latency vs. Reordering (Was: Remailer ideas (Was: Re: Latency vs. Reordering))
by hughes＠ah.com 17 Dec '03

17 Dec '03

Sigh. I say "A implies B". You say, "not A, and so proposition is incorrect". No, I say that messages distributions are not continuous, so the model which assumes they are is not the right model. IF the traffic is continuous, THEN random delays introduce reordering. I've never said they didn't induce some reordering. That's not my point, which is about known and not merely suspected properties of systems. Cryptography is about assurances as well as actual security. Information security is a negative property; it works when nothing bad happens, and something bad may happen without it being directly observed. Since one can't always see an actual cryptosystem failure, unlike, say, a robbery, the way to extend the security is by understanding what is possible. And for understanding, proof is always better than intuition, guessing, or supposition. I'll reiterate again. Reordering is what yields privacy, directly. Adding latency adds privacy ONLY insofar as it adds reordering. If you feel like you have to have a latency based system, fine, but the understanding of just how much reordering such systems actually induce is still lacking. It does not suffice to wave hands and say it induces 'enough' reordering. You need to know how much, and that takes a calculation, which has not been done yet. Furthermore, I demonstrated two reasons why latency-based systems are less efficient in implementation than reordering-based systems. So, in upshot, latency based reordering is not only less efficient, but also less well understood. Until someone comes up with a latency-based scheme which can't be algorithmically modified to make a more efficient reordering system, and has similar memory usage, and until someone does some calculations on just how much reordering is induced by various latency schemes, I will continue to call latency based mixing by the name snake oil. > Fourth, the problem is incompletely specified, since the distribution > of random added latencies is not made specific. Correct. You assume details that have not been specified, and then critique them at length. By not specifying exactly what distribution of latencies you're talking about, I assume that you are making a universal claim about latency-adding systems with _any_ distribution. I do not see you claiming that there exists some special distribution that makes latency systems work, because for implementation you actually have to exhibit one. Therefore, I point out that this is another lack of understanding. And I _know_ that if you haven't thought before about the issue of the distributions of the added latencies that you haven't thought very hard about the cryptanalysis of such systems. His arguments also ignore the fact that reordering messages of different lengths is useless as a defense against traffic analysis, suggesting that this is polemic rather than a serious argument. Oh, really? You even quoted me explicitly not ignoring the issue: > Encyphering is necessary. Reordering of quanta is necessary. The phrase "reordering of quanta" seems perfectly clear to me. Eric

1 0

IDEA vs DES
by Phil Karn 17 Dec '03

17 Dec '03

Now that I've got DES running about as fast as it can go on the 486, I did a little analysis on IDEA. The algorithm is definitely more straightforward to implement than DES, but not necessarily that much faster. It uses three primitive operations, all on 16-bit quantities: XOR, ADD and multiplication modulo 65537. Each encryption involves 48 XORs, 34 adds and 34 multiplies, plus a few exchanges. The multiplies are a problem. On the 486, a 16x16 integer multiply takes from 13-26 clocks, depending on how many significant bits there are in the multiplicand. Random data usually has 15-16 significant bits, so this distribution is probably weighted more toward the 26 clock figure. So I count an optimistic total of 990 clocks per 64-bit encryption, assuming plenty of registers (which I don't have), not counting the modular reduction steps for each multiply, and ignoring the memory references for the subkeys. I figure my DES code is currently taking about 1300 clocks per encryption. So IDEA won't be much faster, though it may be more secure. Anybody know the speed of the integer multiply instruction on the various PowerPC chips? Along with modular exponentiation and vocoders, which also do a lot of multiplies, it looks like fast multiplication is becoming rather important in secure communications. Phil

5 4