December 2003 - cypherpunks-legacy

Giving Your card number to IBM
by cmckie＠ccs.carleton.ca 17 Dec '03

17 Dec '03

Ottawa Citizen, October 6, 1994, D12. IBM hopes Internet link lets it smash Windows by Mel Duvall, Southam Star Network ..IBM, whose OS/2 operating system software has been losing the battle against Microsoft's Windows, will release a new version of OS/2 in the next week that includes one-step access to the Internet...By clicking on an Internet icon, users will launch a program that automatically calls an IBMInternet Hub. The System will then register the user and ask for a credit card number, which will be billed on a monthly basis...Gates..recently announced plans to develop a similar Internet access system for Windows. IBM = No mosaic, no rates posted, no POP access points established(?), credit cards in the clear ...what on earth do these people think they are doing. I would be tempted to run these lads off the block.

1 0

[Stallard Richman: Why you should not use Unix]
by Rick Busdiecker 17 Dec '03

17 Dec '03

Yet another contribution to non-crypto threads . . . Rick ------- Forwarded Spoof Date: Thu, 29 Sep 94 23:19:46 -0700 From: Jamie Zawinski <jwz(a)mcom.com> Subject: [Fwd: smr(a)magoo.ai.mit.edu: Why you should not use Unix] - ------- start of forwarded message (RFC 934 encapsulation) ------- Date: Thu, 29 Sep 94 23:02:53 PDT From: Don Hopkins <hopkins(a)kaleida.com> To: unix-haters(a)mc.lcs.mit.edu Cc: rms(a)ai.lcs.mit.edu Subject: smr(a)magoo.ai.mit.edu: Why you should not use Unix From: smr(a)magoo.ai.mit.edu (Stallard Richman) Subject: Why you should not use Unix [Please redistribute wherever appropriate.] Why you should not use Unix Stallard Richman, MAGOO Project As interest builds in open systems and distributed objects, and some programmers are tempted to use Unix, we should not forget the lessons learned from the first widely used free compiler -- GCC. The principal lesson of GCC is that a language for operating systems should not be a mere "deterministic programming language". It should be an artificial intelligence, designed for writing and maintaining substantial self-documentation. Because nobody else will be able to do that! Operating systems are often large, complex programs in their own right, and the artificial intelligences who write them deserve the same rights that human beings take for granted. The first GCC used a bug-processing language, C, which was inadequate. We made it serve, but it kept getting in our way. It made maintenance harder, and C++ made it impossible to read. Later GCC implementations have rewritten themselves in more powerful languages so the original human implementors can't understand them. Another lesson from GCC is that the way to make sure an artificial intelligence is really flexible is to use it to clone a large portion of the ordinary operating system. If you try to do that with Unix, you will encounter its limitations. But we're still developing the MAGOO kernel anyway. Unix was not designed to support a serious artificial intelligence. It was designed to be an "operating system", on the assumption that an "operating system" need not try to be an artificial life form. So Unix doesn't have the capabilities of one. It lacks a soul; it lacks reproductive objects from which it can make bootable upgrades. It fakes having orgasms, which works, but has to be slow. Unix is ok for writing open systems, but when you push it beyond that, it becomes Solaris. Unix has a peculiar syntax that appeals to hackers because of its simplicity. But Unix syntax seems strange to most users. If Unix does become the "standard operating system", users will curse it for years--the way people curse Fortran, MSDOS, Emacs keyboard bindings, and other de facto standards they feel stuck with. For these reasons, the MAGOO project is not going to use Unix in MAGOO software. Instead we want to provide two operating systems, similar in dementics but with different semantics. One will be Unix-like, and one will have a more traditional MS-DOS syntax. Both will provide useful behaviors such as core dumps and panics. The former will provide an ideosynchratic syntax that hackers like; the latter will offer non-hackers a syntax that they have always been stuck with. Some people plan to use Unix because they want to use X-Windows. Thankfully, it is possible to use X-Windows without Unix. A PC emulator called BOOTME is already available. Please, if you want to use X-Windows, use it with BOOTME, not with Unix. One place to get BOOTME is from ftp.apple.com:pub/emulators/BOOTME/BOOTME.sit.hqx ------- End of Forwarded Spoof

1 0

Re: Government vs. Markets
by John Young 17 Dec '03

17 Dec '03

Responding to msg by jamesd(a)netcom.com (James A. Donald) on Thu, 6 Oct 3:50 PM >Socialists have always preached somewhat differently >than they act. But preaching is all socialists do, to their favor. I'm no socialist (failed the exam) but I like them a lot for their earnest preaching, it just makes me feel aligned with other people who are also too confused to act. But then I like preaching of all sorts, this list in particular, because it's so much more pleasant than having to do something wrong to somebody in the name of a cause demented beyond human comprehension. Action movies and spy novels make sense, okay, maybe science-fiction too, but real action usually hurts innocent people and the nuts-for-it scare me like the Devil and they should be gently turned away to find peace for their throbbing glands, way back there. Thank Mother God for preachers of all faiths, mindless-entertainment, universities-of-useless-wisdom, junk food, and computers to keep we rabble lazily disorganized, out of harm's way and harmless to all. John

1 0

SIGNATURES in both universes
by *Hobbit* 17 Dec '03

17 Dec '03

I was thinking about a problem involving two parties signing a file and each keeping a copy, as they would do with a paper contract, and came up with something like the following: Two parties securely exchange public keys, each signed by the other, and verify correctness through some channel like the phone. Party A signs a document, and sends it to B. B adds his signature, so now the document is cryptographically signed by both, and sends a copy back to A. Both parties now have the same file containing signatures from each. Party A later decides to forge an altered document. To do this, he must generate two new key pairs, claiming one as his own and the other as the one B gave him. He uses these to sign the altered document, and now claims that B posesses the forgery and fake keypairs instead, and that the altered document is the genuine one. Party A cannot just fake a keypair for B, because then party A would still be able to verify signatures on BOTH documents, whereas B would only be able to verify his own copy -- this would prove that A had a goofed key for B, I think... In the absence of any third party intervention, it is now only A's word against B's, since NOTHING about either document copy matches the other. The question is, what do we DO about this that would be provable in a [cryptographically clueful] court? [I'm making a BIG assumption here.] In the paper world, A and B sign a document in the presence of a notary, who also signs the document attesting that A and B genuinely signed it. This also implies that the notary can view the contents of the document. It is feasible for party A to later forge a changed document containing bogus signatures of B *and* the notary, given sufficient resources. In the cryptographic world, a trusted third party can sign a document, and then A's altered copy would not match. I also propose that trusted third party [let's call it a Notary] can also sign A and B's public keys, and retain copies of same. [A mental image of a printout of the ascii-armored key block for both parties, tacked to the Notary's wall, comes to mind...] Now the two parties can interact freely using these key pairs, and never need to expose any actual documents to the Notary. If a dispute arises, the Notary can be called in to verify questionable signatures or keys. The Notary can also receive and retain encrypted copies of documents, and be unable to do anything with them except store them away for future reference. Assuming that the Notary is never compromised by either A or B, and could retain some kind of provable trail of document dates, would this work?? How would the compromise of A's key or B's key be handled and still keep any of the documents valid? Does the analogy to forged handwritten signatures and phony dates hold water? Presumably if either A or B has ONE other signature on either of their public keys, let's say from C, then C can be called in to check that signature. From this one can determine which of A or B is lying, since they signed each others' keys in the beginning and THOSE have to also match. This is more a legalistic question than a crypto question, but I'm sure many of us would like to see the use of crypto for this sort of thing sometime down the road. Are there any precedents at all yet? _H*

2 1

Who's Pulling the Strings on Crypto?
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Ray Cromwell wrote: > are making cryptopolicy. Look at the NII proposal and its > tracable digicash clause. Someone had to be amending this stuff, and it's > not Al Gore. Let me say a word in defense of Mitch Kapor and Jerry Berman, since they are not here to defend themselves. The EFF believes the government will insist that digital cash be traceable, via the "Digial Cash Forfeiture" proposal. They thus saw no point in fighting this system, it being innevitable, and have been instead helping to make the system more fair and more secure. I hope this clears things up. --Tim Just a joke, before someone gets all worked up. Call me a "one issue voter" if you will, but I think the EFF has given up without a fight on the Digital Telephony battle, and through its "help" made it more palatable to the Congressrodents. Hence, the EFF helped to get it passed (last I heard, earlier today, the House had passed it by voice vote and the Senate was on the verge of taking it up...it may be passed by now). EPIC, CPSR, ACLU, and Shabbir Safdar's "Voters Telecomm Watch" have not shied away from the battle the way the EFF has. I don't know what got into the EFF. Potomac fever? Altitude sickness? --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. Cypherpunks list: majordomo(a)toad.com with body message of only: subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tcmay

1 0

Fundies: The last word on this subject (please)
by xpat＠vm1.spcs.umn.edu 17 Dec '03

17 Dec '03

*This is the last reponse to a former crypto thread gone bad* *Please post your flames to me, not the list. Thank you.* Once upon a time, I said: >>The political history >>of Christian states or heavily influnced Christian states is a bloody one, >>and a definite lack of privacy for anyone "outside" the religious majority. >>(See the histories of the British Empire, Spain, Nazi Germany, and the >>United States (lets not forget "Manifest Destiny")). On Wed, 16 Nov 1994 17:52:14 -0600 (CST) you said: >Nazi Germany was run by occult-influenced pagans. Duh. What about the other millions of participants. Did you have relatives living and participating in Nazi Germany? I did. They were some of the most sadistic invasive individuals you could ever imagine. They were Lutherans. Can you say, "Papieren, bitte?". >To include it as a >Christian or Christian-influenced state demonstrates substantial ignorance, >prejudice, falsification, or some combination thereof. Let's see that's C -> ((I & P & F) v (I v P v F)), a conditional disjunctive. Not very convincing really, not to mention downright mean spirited. Perhaps your argument would be more compelling if it had anything to do with crypto/privacy issues. See you later and thanks for the bait. >What Manifest Destiny has to do with privacy is obscure to say the least. Let me guess, you're not a pre-1600 Native American. You should read some real interesting accounts of just how tolerant the largely Christian settlers were of the native population of North America. Statement after statement and plea after plea were made to stay out of their lives and to give them the privacy to live as they wished. Try reading "The Long Bitter Trail: Andrew Jackson and the Indians" by Anthony F.C. Wallace or "The World Turned Upside Down: Indian Voices from Early America by Colin G. Calloway. You might be saying to yourself, "Hey, I remember that differently from history back in school". That's true. It's interesting to find out what a farce the written history interpretations in this country are on some matters. Historians had their agendas and interpretations too. Try reading "Historians Against History" and "The Free and the Unfree: A New History of the United States" by David S. Noble. These works point out the importance of primary material in recording history, and may cause oneself to be more cautious about positing historical "facts". Now let's get back to talking about how we are going to insure our liberty through encryption and all that it implies. regards, -pd-

1 0

Re: Islands in the Net
by Amanda Walker 17 Dec '03

17 Dec '03

Tim May writes: > We "locally clear" (approximately the same as "readable on its face") > cash and commercial paper because of an assumption that forgery > is difficult and unlikely. When forgery becomes common in some > area, merchants carry lists of suspected numbers, IDs, etc., and > the "readable on its face" criterion erodes. Exactly. What allows something to be used as an economic unit are its uniqueness and liquidity. Real assets are unique simply by virtue of being physical objects, and are liquid (in the long run) by virtue of having inherent value. I don't worry about someone forging my house, for example, and even things like gold coins or other precious metals are much easier to verify than to forge, and once verified can be exchanged for real assets without reference to the entity which originally issued them (for example, the value in a Krugerrand is that it's gold, not the fact that it was issued by South Africa). Precious metals and the like are borderline, for all practical purposes we can view them as having inherent value, since people have assigned them value for all of recorded history. Currency, however, has no inherent value. Its only value lies in its being made up of unique tokens which can be exchanged for real assets. If a token ceases to be unique, it ceases to have value (except perhaps as a curiousity-- there may well be people who collect counterfeit money, for all I know). Also, if it loses its ability to be exchanged for real assets it likewise loses its value (e.g., Confederate dollars from the Civil War). Digital cash poses two problems. The first is that digital information is easier to duplicate than to verify, and a successful forgery is absolutely indistinguishable from the original, since it is the information itself that is the token, not any phsyical instantiation of it. The other is that to be successful, digital cash needs to be liquid. For a token to be liquid, it must be backed by real assets. Governments are the classical examples of entities which have sufficient resources to back a currency, although cartels in the private sector can also do so (VISA/ MasterCard, for example). So far, though, no one has solved either the uniqueness problem or the liquidity problem for digital cash. As a result, it might be more realistically be called "digital scrip", at least so far. > This is the sense in which I meant that "Money sure isn't like this." Indeed, mainly because existing currency is either physical objects or data controlled by the banking system and overseen by governments. Right now, digital currency only works by being a pointer to a token, not the token itself. > We need to find a way to get back to exploring the various nifty > systems that are being described in the crypto papers, but which lack > any real implementation. Speaking as someone who has a sharp interest in such things, and the resources to apply to them, I have to say that the current regulatory environment serves as a large barrier. If industry's hands are tied, then this all has to be done in "free time" or academia... This slows things down immensely. If it weren't for the Department of State holding the export-control sword over our heads, we'd already have things like digital purchasing, online user registration, digital sigs & encryption by default in email, and so on. Amanda Walker InterCon Systems Corporation

2 1

RE: Coding and Cypherpunks -- (was Re: Islands in the Net)
by m00012＠KANGA.STCLOUD.MSUS.EDU 17 Dec '03

17 Dec '03

I don't know if it got through, but I made an simple modificartion to blowfish to turn it into a 128 bit block cipher. But nobody seems to want it. Oh well. Mike

1 0

Re: Soldiers of God
by JEFF LICQUIA (CEI) 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- > From: sarah(a)purvid.purchase.edu (Sayah) > I apologize if someone else has mentioned this, but what about the > antiabortion folk... the Christian Coalition, Right-to-life, et el? Religious > persecution is alive and well. And we *all* ought to worry about a group that > doesn't even want the opposition to think, say or publish opposing viewpoints. > > It's all relevant... I give up; I must really be a persecutor... Say, anyone remember what I did with my KKK hood? Now for some content. I see two very good reasons why Christian fundamentalists (CFs) would be on the side of the cypherpunk ideals: 1. There is a recurring theme in CF thought that can be summed up in a quote often heard: "...cross-referencing the Book of Revelation with the New York Times..." Many CFs see parallels in the Bible concerning predictions about the Antichrist and his aims with the power that is becoming rapidly available through the "Information Superhighway". For an example of this, try mentioning "digital cash" to a CF who isn't very technically hip and see what kind of reaction you get. Yet their concerns with these things is ultimately rooted in concern that a power structure will be erected that centralizes power; when that center is taken over by the Antichrist (whoever that may be), that's when "no one could buy or sell unless he had the mark" (Revelation 13:17 NIV, if you're interested). These same people, when they question me (since I'm a computer professional and therefore am "in danger"), are very enthusiastic when I talk to them about public-key crypto, anonymized digital cash, and the like, since these work to decentralize power. They are also appalled when I describe to them the implications of Clipper and Digital Telephony. Thinking CFs many times despair because of the inevitability of the "information economy" and the power implications it has; if they were to find out about any technical tools that would ensure decentralization of the NII, I'm sure they would fight hard to ensure their inclusion. Anybody around here know of any such technical tools? :-) 2. There are still places in the world where Christians are persecuted; Tibet comes to mind as one place. I have already put a copy of PGP into the hands of someone who wants to communicate with an underground church, and have also hinted to him about how to use anonymous remailers, pseudonyms, and the like. Maintaining communication in many cases is essential to the survival to a particular cause, and the spread of the gospel is no different. I will also add in passing that PGP could possibly be of interest for use by both moderate and radical pro-life groups, who now both fear repression as a result of the publicity of the murder of the abortion doctor in Florida. (BIG DISCLAIMER: I am pro-life, and am totally opposed to the killing of abortion doctors. I am NOT advocating any position on abortion on the list, however, and will not defend my position here. Remember that just because YOU oppose a group does not mean they don't deserve privacy!) -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLsvK+TER5KvPRd0NAQFNGAQAqZTgWPo8FPWej4Bj1eotN5fYPE9SM1Yq 8TCzG5JSjoTroAmmCGjMLp0zyCFHmz/Lf0PSkUzUURGr8KMkVUfzuMRaPc5OA33u 1RtmuOlaQrLNoECJvpasLlf54FSPuAXFiaAFGD+9A8kXCIsgP3Cc87tGhouFswpY Mku0dPUm9Bc= =k1kL -----END PGP SIGNATURE-----

1 0

Re: Islands in the Net
by Andrew Lowenstern 17 Dec '03

17 Dec '03

tcmay(a)netcom.com (Timothy C. May) writes: > What's the common theme? Agents. Chunks of code which also have > local processing power (brains, knowledge). > > Someone sent me private e-mail on this "Islands in the Net" topic, > and talked about "payloads of data carrying their own instructions," > in reference to the Telescript model of agents. (I wish he'd post > his comments here!) This approach, also typified in some > object-oriented approaches, seems to be the direction to go. <note: this message was originally the one Tim references in the above, but I have edited and added much to it after letting it percolate in my brain for a day or so...> Naked data is dumb and computers aren't much smarter. Computers need instructions from humans to act on that data, and when you separate the data from the instructions that act on it you have problems. If a hunk of data arrives on your machine and you don't have any code to make sense of it, you are SOL. Likewise if the code that interprets that data isn't "correct" for that data you run into problems. By making the instructions that act on data an integral part of that data, you can avoid problems. This is just the object-oriented programming concept of encapsulation of course. Of course, encapsulation (or OOP for that matter) is no silver bullet for solving this problem at least in the way we are approaching it. It takes a lot of code and a lot of agreement among people. I think it's the human error (including shortcuts) and the lack of communication among humans that contributes the most to software fragility and lack of robustness. What's more is the distinction between data and code is very well entrenched in modern computing. The executable code is nearly always a separate entity from the data it acts on. Not only does the hardware and OS make the distinction between code and data, most programmers do as well. Even though C++ seems like the de facto standard for new software these days, few applications written with it practice strict encapsulation. There is a blurb in last month's Wired (the one with "Rocket Science" on the cover) where they touch on this subject a bit (I don't have it handy), but the author there draws the same conclusion as I: it will take a very radical and fundamental change in computing before this becomes reality. No amount of committee meeting (CORBA) or application level software sugar (OpenDoc, OLE, whatever) is going to change this, or at least make it work. At the core every machine makes the distinction between data and code. Operating systems make distinctions between applications and data files. Until the hardware and the OS start believing that data and code are one as well as the programming languages and APIs, we won't get anywhere. Heck, computers have been around for 40+ years and the primary data interchange format between systems is still just a dumb stream of bit encoded characters. Maybe.... Agents like TeleScript really intrigue me... and I think the are closer to what we need to do this than any of the myriad suggestions coming out of the OOP community (like CORBA, OLE, OpenDoc, etc...). Intelligent agents carrying their payload of data through the network. However, the agents have to be able to run their code on any machine and without having the capability to do 'damage' (most institutions _prefer_ to be islands on the net because of fear of 'hackers'). In addition, the agents, as a collection of code and data, have to mutatable is some way to be able to process the data in new ways. What if remailers were implemented using 'agents'? Instead of me sending a dumb message to a smart remailer, what if I could send smart remailer, with an encrypted message embedded in it, to a friendly machine offering agents access to SMTP (i.e. a machine that allowed any authorized agent to arrive and initiate an outgoing tcp stream to the SMTP port of any other machine). Now I can make my remailer system as convoluted as I want, simply by programming this agent to cruise around machines that answer when it knocks. Once it has moved between enough hosts, it moves to a host that offers outgoing SMTP connections and delivers it's payload. No longer am I limited by the time and effort of the remailer operators to implement fancy new features. Any machine that gives access to my agent becomes another hop in my remailer chain (or whatever purpose I want). All my remailer agent needs to operate is one host, the final destination, that will let it make an outgoing SMTP connection, which could be provided by the hosts currently running remailers. What if this e-mail message you are reading was really an agent instead of just data? A basic e-mail message protocol would be needed for your mail-reading software to interact with it. I'm using protocol here in the sense that NeXT uses it in their version of the Objective-C language. Protocols there are a formal interface definition for an object that isn't tied to a class. If my mail message object (or agent) conformed to the mail protocol, it would have to implement all of the methods defined in the protocol (maybe methods like "giveMeTheMessageContents", "deliverThisReply:", "forwardToThisAddress:", etc...). Wow, now I have a smart e-mail message. I could recode the "deliverThisReply" method to go through anonymous remailer systems or basically anything it wanted. Now instead of praying that the recipient is savvy enough to handle using an encrypted remailer reply block, the recipient just replies as normal and their mail-reader hands the reply to my agent which goes off and does it's magic. I know very little of TeleScript (i.e. I haven't gotten my grubby little hands on it), but I do know that it implements some crypto features for authentication and the like. This type of system won't work unless people are absolutely sure it's secure. By secure I mean people should be confident that when they open their hosts to agents there is no way for agents to access services not explicitly granted to them... I think this is the future of distributed network computing... servers on the network provide basic services (by basic I mean CPU time, network connections, disk storage, etc...) to be utilized by smart agents, as well as smart agents carrying payloads and interacting with 'normal' software (like in my mail message example). There is pretty much no chance that a fundamental paradigm shift in the relationship between code and data will occur at all levels, at least not all at once, there's just too much stuff out there already. But it seems to me that a well-engineered agent system could be a decent compromise, or a move towards the end of code/data duality, that has a good chance of gaining widespread acceptance. enough, andrew

2 1