December 2003 - cypherpunks-legacy

No Subject
by nzook＠math.utexas.edu 17 Dec '03

17 Dec '03

nomath 5 19% discrete 7 27% algebra1 4 15% algebra2 3 12% grad 3 12% orals 1 4% orala 2 8% research 1 4% total 26

1 0

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

17 Dec '03

I was thinking some about remailers and means to create more effective ones. I think the idea of padding messages has been kicked around (has anyone implemented it?), but what about random compression? Some messages are compressed, others are padded, some are left alone, perhaps shooting for a median message size (everything coming from this mailer tries to be 9k, or as close as possible). Of course, this requires a standard so that other remailers downstream can make the message readable. Another thing that occured to me is the thought that if there were an organized web or remailers, remailers could bounce messages between them automatically- a header could identify the number of bounces perhaps, I haven't thought too much about the implications of doing so, but if every message through the web bounced around 30 times with reordering, padding/compression, PGP, etc. then traffic analysis would be pretty damn hard, I would think, even for someone monitoring the entire web of remailers' traffic. This all assumes that: - remailers can agree on a standard for the above needed features - a semireliable web of remailers can be maintained - some method fordealing with denial of service attacks can be found (a coredump sent to the web could play all sorts of hell, as could an 'evil' remailer that sneaks in and changes the how-many-times-through identifier). The third problem could be delat with by deciding on a size limit- if a message is over 65k (or whatever) it is bounced- if you're sending something big, split it. The first one could probably be done- if someone (grin- if I find any time soon, this is a project I'd like to do) wrote a nice package that was easy to install and use with a feature set that could be agreeable to most. The second one is the problem, but could be dealt with by the first by establishing automated communication- when someone installs the package, send a control message another remailer already part of the web which 'registers' it, and then the web consistently tries to maintain itself by checking on the others and dropping ones that go down off the list. Some sort of method would have to be found for ones that drop off then later come online again so that control messages didn't have to be manually initiated every time, but that shouldn't be that hard. What are the problems in the above? Would Perl be a good choice for doing this? I saw some code from a remailer some time ago, but lost my mailbox a while back (which could also mena that this is a dry rehash of an old discussion... apologies if I am rewriting someone elses thoughts). Anyone still have this? Am I talking out my ass? -j -- "Blah Blah Blah" ___________________________________________________________________ Jamie Lawrence <jamiel(a)sybase.com>

3 2

One more time... us.*
by L. Todd Masco 17 Dec '03

17 Dec '03

[Very little c'punk content, just explaining why the us.* proposal is nothing like a movement towards censorship, but an attempt to resist it] First, you have to understand that nobody has any say over what newsgroups are created on a machine except for the news admin on that machine. Most news admins hand this authority over to Dave Lawrence, the current moderator of news.newgroups.announce, when they install their news software. However, *anybody* can decided to ignore anybody else's decisions on *any* newsgroup and issue a newgroups message (and someone else will usually issue an rmgroup message in response: it's an anarchy, and most of us like it that way). The us.* hierarchy "cabal" idea is *not* to determine what groups will get passed and what ones will not; In fact, the intent is to eliminate "no" votes, passing groups only on the basis of significant interest. If you know any USENET history, you'll know about fiascos like the soc.culture.tibet, soc.culture.macedonia, and soc.religion.islam.ahmadiya proposal -- cases where the newsgroups had a significant amount of interest, but were defeated due to large populations having some sort of grudge or religious/national interest in supressing a point of view. This part of the proposal will, in fact, reduce censorship, preventing organized campaigns from defeating newsgroups, effectively preventing people from discussing their subject on USENET (for the traditional definition of USENET that excludes alt.*). The other part of the proposal, the one which seems to have pushed people's "censorship" kneejerk buttons, is the concept of the "namespace cabal." Again, if you have any knowledge of USENET history, you'll know that there used to be a far stronger cabal than is proposed by the us.* idea: the backbone cabal controlled everything -- they were the news admins at the backbone sites and they had the last word. News admins at other sites listened to them because, well, they were the backbone cabal. They had the connectivity. When the set of newsgroups became too big for news admins to effectively manage them (and the connectivity model changed, there no longer being a real news backbone), a newer system for gaining consensus over newsgroup creation was created. Votes would be taken -- *NOT* on democratic principals or anything of that nature, but simply to gauge interest so that news admins would have some basis on which to approve group creation. Over time, the formula was tweaked in various ways when groups that people thought should never have passed (like the rec.acquaria, sci.acquaria, etc. groups) were created. Still, this is basically the system we have today. As I mentioned above, the current model allows large groups of people to squash newsgroups of interest to smaller (or even equal sized, since the current guidelines require 2/3 majority to pass) groups. THAT is censorship, the tyrany of the majority. There is also another thing that needs fixing. There is a problem with the current USENET namespace management strategy: it is damn near impossible to manage a namepsace by vote. In extreme cases, Dave Lawrence has simply refused to publish the newsgroup creation message, but nobody is very happy with this: it's too much like Dave is censoring the net, and it's wrong to stop the creation of a newsgroup on a subject simply because its proponent insists on a name noone likes. As a USENET volunteer votetaker, I have become embroiled in proposals for groups where a vast number of people wanted a newsgroup but had to wait months, sometimes missing the opportunity to discuss events important to them, because the newsgroup proponent was insisting upon a name that nobody agreed with or because no clear consensus (among users) appeared about the naming of the group. It is the namespace issue that the proposed "cabal" will cover. It's no different than the government refusing to take a vote on where every single book in a public library will end up on the shelves or where each document is stored. Namespace management is simply impossible to do by voting, especially when the "voters" have no understanding of the issues involved. We've squeeked by so far, but only barely -- and as the net grows, it become much more difficult to maintain the current voting scheme. That is why it is absurd to view the "namespace cabal" concept as an attempt to censor a democratic form. It isn't an attempt to censor (it is an attempt to stop censorship), and the current form isn't democratic. Please, before you try to argue this -- check out the facts about the proposal, the history behind it, and the real mechanisms in place before you spout off. -- L. Todd Masco | Bibliobytes books on computer, on any UNIX host with e-mail cactus(a)bb.com | "Information wants to be free, but authors want to be paid."

1 0

Re: GUT and NP
by Ray Cromwell 17 Dec '03

17 Dec '03

Bezerk's original comment makes two assumptions. 1) continuum phenomena are real and space is not merely quantized at a level which is undetectable by experiment (just because physics models it as a continuum doesn't mean it is so) 2) all of this precision actually makes a difference For instance, at the level of brain chemistry, who cares about quantum precision when thermal noises will swamp it anyway? (the Penrose argument even goes as far as assuming quantum gravity, a force pitifully weak, as a signficant factor) One of the reasons digital manipulation became popular was because analog data was too prone to error. Why will a quantum computer, which seems even more sensitive to external perturbation, be any different? And regardless of whether quantum computers work or not, they are still algorithmic if they can be simulated (however slowly) by a turing machine. It's a rigorous mathematical definition. Claiming otherwise uses algorithm in a manner different than was intended. It's like the way Ludwig Plutonium solves all those famous problems in sci.math by assuming different definitions of primality, etc. Quantum computers might be faster than classical computers, but non-algorithmic, I don't think so.

4 7

RE: What can one do for remail operators? (fwd)
by David Merriman 17 Dec '03

17 Dec '03

> > I think the single most important thing we could do for remailer operators > would be to figure out how to make the remailers *truly* *anonymous*. That > is, we need a net.hack of some sort that allows remailers to send their > messages in a way that leaves no trace whatsoever of the original poster > *and* leaves no trace of the remailer itself. > > Net.veterans will perhaps recall a thread I started a while back along > these lines... this is a technical problem, and I have the utmost > confidence that the skills to solve this problem are around here somewhere. > If I may make a humble suggestion, I would suggest that this problem is > more immediate and pressing than many of the issues currently being > debated. > One option might be for the remailer to forward messages giving a false ID/address - essentially, lying about who they are and where they live :-) That would seem to take care of the outbound traffic; how to deal with the inbound traffic is an exercise left for the reader ;-) Dave Merriman

1 0

Latency vs. Reordering
by Jeff Gostin 17 Dec '03

17 Dec '03

hughes(a)ah.com (Eric Hughes) writes: > For the Nth time, it's not latency, it's reordering which is important. True. For small numbers of files re-ordering is important. On the large scale, latency serves both purposes. I tend to think of these things on the large scale, which is the reason I pointed things that way. --jeff

2 1

RE: Questions about Microsoft and Software Key Escrow
by John Young 17 Dec '03

17 Dec '03

Responding to msg by Jacob.Levy(a)Eng.Sun.COM (Jacob Levy) on Thu, 28 Jul 7:53 AM > >Blanc > >I respect your feelings on the matter and your ability >to think clearly and with great foresight also :-), >but for this list it would probably be much more >useful if we got some _OFFICIAL_ answer from Microsoft >instead of your "I believe, I cannot think, can't >see", etc. etc. You're obviously a concerned >individual but you equally obviously don't claim to >speak for Microsoft. > >--JYL Would it not be fair to ask that all the parties earlier listed by Tim -- Microsoft, Sun, Apple, IBM and others -- be asked for an official statement of their positions on SKE? Even so, will this produce credible statements? What if confidentiality or secrecy agreements are already in place? Disinformation needs cryptanalysis, no? John

1 0

Re: DES Vulnerable, Why?
by koontzd＠lrcs.loral.com 17 Dec '03

17 Dec '03

>My question: if triple-DES is so damn tough to break, what is wrong with DES? > Triple-DES is a trivial variation on DES. Brute Force Key Search ala' Weiner.

1 0

Dallas Morning News article?
by Phil Karn 17 Dec '03

17 Dec '03

I've heard that an article appeared in the Dallas Morning News, apparently yesterday (wednesday) on the absurdity of crypto export controls. I understand that I was quoted in reference to my CJ requests for Bruce Schneier's book and floppy disk (which is not surprising since the writer interviewed me last week). Does anybody have a copy of this article? I have no easy way of getting a copy. Phil

1 0

"Just say NYET to NYET"
by Brian D Williams 17 Dec '03

17 Dec '03

I appreciate Nathan's openness and honesty about the inherent biases that affect his life. In numerous dealings with the religious right I've found that hard to come by. I also appreciate the fact that he is a strong believer in privacy, although privacy, in his view, seems to be something restricted to adults. Censorship is an attempt to apply Paternal/Maternal authority outside the family unit. A place IMHO it does not belong. I see the internet somewhat differently though, I see it as another world, that just happens to be accessable from our own, kind of like America was about 500 years ago. The only difference is that it was previously uninhabited. I like it the way it is! Now like the other world I occupy, here comes the religious right, who aren't content to live there own lives, there going to tell me how to live mine. (for my own good of course!) No way Dude....... I've fought your kind before, and knew it was only a matter of time before I'd have to fight you here. I for one am ready. I thought Hal Finney had an excellent suggestion, why not form your own private family values or whatever access provider, you could censor to your hearts content! That would save ya'll from having to move to Singapore or some other La-La land. Just another unwashed, uneducated, heathen, savage, heretic.... Brian Williams Extropian Cypherpatriot "Cryptocosmology: Sufficently advanced communication is indistinguishable from noise." --Steve Witham "Have you ever had your phones tapped by the government? YOU WILL and the company that'll bring it to you.... AT&T" --James Speth

1 0