- cypherpunks-legacy - lists.cpunks.org

Stallman & Ousterhout && (TCL || !TCL) && practicing cypherpunks
by strick＠yak.net 17 Dec '03

17 Dec '03

[ this is a repost of an attempt to send this yesterday --strick ] -----BEGIN PGP SIGNED MESSAGE----- > On gnu.announce of 9/23, he writes "Why you should not use Tcl". > Instead, those wanting to use the Tk tools are commended to a > Scheme interpreter with it called STk. Available from: > ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z Below is the post from Rich Stallman "Why you should not use Tcl", and the reply from Ousterhout, which is basically: Why you should not listen to Stallman, in this case. The mentions in the [fantastic] Cyphernomicon of TCL are probably due to my crypto-prototyping project. I did not take the choice lightly when I chose TCL as my "glue" in this project. Two issues that may be interesting but had *little to do* with my decision are (1) language support for big numbers and (2) the TK toolkit (which happens to be in TCL). The reason I chose TCL is that it is designed to work above, underneath, and alongside of C code. TCL has two published interfaces: one is the language and standard commands, and one is a C API for use in combining the language with other C packages. I think of TCL as more of a subroutine library than a language: in the same way that (say) C++ string, file, and dictionary classes can help you be more productive in writing C++ programs, a "little language" interpreter can make you more productive in many kinds of programs. Crypto prototyping systems is one of them. I am not new to LISP or PERL or AWK or POSTSCRIPT or FORTH or SHELL or BASIC or HYPERTALK or various other interpreted langauges. For many differnt projects I would leave TCL for one of them. However when TCL came along, I recognized it as being just the language I had wanted to write myself for doing projects like my current one. Which may say more about what kind of a computer scientist I am that about what lanaguage is best for you in your situation. I'll add that I have a version of my crypto toolkit that is a PERL interpreter, and I've looked briefly at embedding it in PYTHON as well. My problem now is that I need a chunk of time to port it all and package it on sun4 (currently it's on sun3). My problem is not yet that I need more languages to port to. But i'll be glad to have some people help embed these things in all the popular interpreted languages soon. It would be particularly nice to have some people versant with Macs and PCs to package crypto components on those machines -- in applescript or hypercard or visual basic or whatever would help people write crypt code. Below I repost the original articles by Stallman (the spiritual leader of GNU) and Ousterhout (the author of TCL). I'll also point out my greatest respect for both of them, and for their respective projects. They've both made my job as a practicing cypherpunk much easier. Talk about prototyping environments, but please don't spam the list on religious issues. PERL and PYTHON and SCHEME are all pretty good little languages. happy hacking, strick Cypherpunks write Code, but when do they release it? :) [ thanks to iansmith(a)cc.gatech.edu and boyz(a)hkn.eecs.berkeley.edu for bringing these articles to my attention. ] - ------- Forwarded Messages Date: Fri, 23 Sep 94 19:14:52 -0400 From: rms(a)gnu.ai.mit.edu (Richard Stallman) To: gnu(a)prep.ai.mit.edu Subject: Why you should not use Tcl Newsgroups: gnu.announce,gnu.utils.bug,gnu.misc.discuss,comp.lang.tcl, comp.lang.scheme,comp.windows.x.apps,comp.unix.misc Followup-To: gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme [Please redistribute wherever appropriate.] Why you should not use Tcl Richard Stallman, GNU Project As interest builds in extensible application programs and tools, and some programmers are tempted to use Tcl, we should not forget the lessons learned from the first widely used extensible text editor--Emacs. The principal lesson of Emacs is that a language for extensions should not be a mere "extension language". It should be a real programming language, designed for writing and maintaining substantial programs. Because people will want to do that! Extensions are often large, complex programs in their own right, and the people who write them deserve the same facilities that other programmers rely on. The first Emacs used a string-processing language, TECO, which was inadequate. We made it serve, but it kept getting in our way. It made maintenance harder, and it made extensions harder to write. Later Emacs implementations have used more powerful languages because implementors learned from the problems of the first one. Another lesson from Emacs is that the way to make sure an extension facility is really flexible is to use it to write a large portion of the ordinary released system. If you try to do that with Tcl, you will encounter its limitations. Tcl was not designed to be a serious programming language. It was designed to be a "scripting language", on the assumption that a "scripting language" need not try to be a real programming language. So Tcl doesn't have the capabilities of one. It lacks arrays; it lacks structures from which you can make linked lists. It fakes having numbers, which works, but has to be slow. Tcl is ok for writing small programs, but when you push it beyond that, it becomes insufficient. Tcl has a peculiar syntax that appeals to hackers because of its simplicity. But Tcl syntax seems strange to most users. If Tcl does become the "standard scripting language", users will curse it for years--the way people curse Fortran, MSDOS, Unix shell syntax, and other de facto standards they feel stuck with. For these reasons, the GNU project is not going to use Tcl in GNU software. Instead we want to provide two languages, similar in semantics but with different syntaxes. One will be Lisp-like, and one will have a more traditional algebraic syntax. Both will provide useful data types such as structures and arrays. The former will provide a simple syntax that hackers like; the latter will offer non-hackers a syntax that they are more comfortable with. Some people plan to use Tcl because they want to use Tk. Thankfully, it is possible to use Tk without Tcl. A Scheme interpreter called STk is already available. Please, if you want to use Tk, use it with STk, not with Tcl. One place to get STk is from ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z - ------- Message 2 From: ouster(a)tcl.eng.sun.com (John Ousterhout) Newsgroups: gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme, comp.unix.misc,comp.windows.x.apps Date: 26 Sep 1994 18:13:27 GMT Organization: Sun Microsystems, Inc. There have been so many follow-ups to Stallman's message that I'm not sure there's any need for me to respond, but I would like to say a few things anyway: First, I'd like to encourage everyone to keep their responses cordial and technical, rather than personal, regardless of how strong your opinions are. Comp.lang.tcl has managed to avoid flame-wars pretty well so far; let's keep it that way by focusing on the technical issues rather than worrying about motives. I think that Stallman's objections to Tcl may stem largely from one aspect of Tcl's design that he either doesn't understand or doesn't agree with. This is the proposition that you should use *two* languages for a large software system: one, such as C or C++, for manipulating the complex internal data structures where performance is key, and another, such as Tcl, for writing small-ish scripts that tie together the C pieces and are used for extensions. For the Tcl scripts, ease of learning, ease of programming and ease of glue-ing are more important than performance or facilities for complex data structures and algorithms. I think these two programming environments are so different that it will be hard for a single language to work well in both. For example, you don't see many people using C (or even Lisp) as a command language, even though both of these languages work well for lower-level programming. Thus I designed Tcl to make it really easy to drop down into C or C++ when you come across tasks that make more sense in a lower-level language. This way Tcl doesn't have to solve all of the world's problems. Stallman appears to prefer an approach where a single language is used for everything, but I don't know of a successful instance of this approach. Even Emacs uses substantial amounts of C internally, no? I didn't design Tcl for building huge programs with 10's or 100's of thousands of lines of Tcl, and I've been pretty surprised that people have used it for huge programs. What's even more surprising to me is that in some cases the resulting applications appear to be manageable. This certainly isn't what I intended the language for, but the results haven't been as bad as I would have guessed. I don't claim that Tcl is without flaws. Some of the flaws, like the lack of a compiler and the lack of module support, will get fixed over time. Others, like the substitution-oriented parser, are inherent in the language. Is it possible to design a language that keeps Tcl's advantages, such as simplicity, easy glue, and easy embedding, but eliminates some of its disadvantages? Almost certainly (there are several decisions that I would re-think if I were starting over). Is the two-language approach really the right one? I still think so, but reasonable people can disagree. Language designers love to argue about why this language or that language *must* be better or worse a priori, but none of these arguments really matter a lot. Ultimately all language issues get settled when users vote with their feet. If Tcl makes people more productive then they will use it; when some other language comes along that is better (or if it is here already), then people will switch to that language. This is The Law, and it is good. The Law says to me that Scheme (or any other Lisp dialect) is probably not the "right" language: too many people have voted with their feet over the last 30 years. I encourage all Tcl dis-believers to produce the "right" language(s), make them publically available, and let them be judged according to The Law. - ------- End of Forwarded Messages -----BEGIN PGP SIGNATURE----- Version: 2.4 iQBVAgUBLpMs6Qq3IMgMJUNlAQGl8gH/WxquXwsd7RbN/Pv8mLwajyZVIN1d53AX TSEtB/grWxbTyUYgPnAu/mzEj33DFPkfttP4/jvdDZir/HsCOxBM5A== =EZgM -----END PGP SIGNATURE-----

1 0

Re: I Like ASCII, not MIME and Other Fancy Crap
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

Tim wrote: >I really do feel we're on the edge of chaos here. Every day that >passes I get more junk mail, more MIME mail, more > 80 column mail, >etc. Yes, the solution is for me to either filter this junk out >or to jump out out to the bleeding edge myself. Re-reading the above paragraph, you know that in the long tern there is only one answer. >But many people won't. We risk losing our lingua franca in a >transition to chaos. There are a lot of new tools out there. Some will survive the test of time, others won't. But if anything, there is less chaos today than there was two years ago. Two years ago, nobody used URLs. They typically described the location of a file as such: "You can get the file at ftp foo.bar.com, its in the pub/mac directory, I think it's called wonder.sit." So you hit ^Z to get out of tin, type ncftp, type all the stuff above, hope it is right - it probably isn't - find the file, get it, type "quit", type sz wonder.sit, get up to fetch a cup of coffee instead of just sitting there and staring at the screen while the file is being transfered to your machine, drink the coffee, ten minutes later you type "fg". Back to tin. Neato, isn't it? Today, most posters on USENET have learned to use URLs and it has become easier to do so, because more and more programs supports them. This is how the above exchange works today: I read my news with Newswatcher. Someone mentions the new hot piece of software at ftp://foo.bar.com/pub/mac/wonder.sit. I option-click anywhere on the URL. Newswatcher passes it to Anarchie for retrieval in the background. I read the next post. I say, burn all the VT52 terminals of this world to fuel the fire of progress. Toss the 2400 bps modems in there, too. I know that few folks will feel sad over the long overdue end of the ASCII era. I can, of the top of my head, name five friends with computers who, after seeing the VT100 display of a shell account, refused to have anything to do with the Internet. "You got be joking. I am not dealing with *this*." Now years later and after much evangelizing and MacWeb demonstrations, they are finally begining to show interest. The dialog was always the same: "I won't have to do any work in one of those terminal windows, will I?" -- "I promise, you won't." -- "Good, because I hate this ASCII garbage." It typically takes me 1-2 hours to install and configure everything on their machines. Yes, it is true, I have spent many hundered hours obtaining the knowlege in the first place, but I am willing to share my knowledge with anyone who asks. As for my friends, they all have been very happy with their new tools. None of them has so far expressed any interest in the telnet client that I have included. Happy netting, -- Lucky Green <shamrock(a)netcom.com> PGP encrypted mail preferred.

1 0

Video encryption & QTC
by paul＠poboy.b17c.ingr.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- [ for cypherpunks: Apple's now beta testing a video conferencing product called QuickTime Conferencing, or QTC. The Mac crypto interface list (mcip(a)feeley.cc.utexas.edu) started a discussion on video encryption, hence this crosspost. Feel free to chime in. ] Here are a couple of additional things to consider. This is a pretty classic application for stream ciphers. Since QTC is transport-independent (and I'd bet it's using OpenTransport calls, too), I'm assuming that QTC is using streams for video data, and that any packetization happens at the transport layer. Just before you call UDPSend(), ATPSend(), or whatever, just whack that outgoing block through the crypto function and off you go. As mentioned, RC4 might be a good choice. It's fast, plus Apple's already licensed it. It probably provides adequate tactical security, but as Adam pointed out, it has not been well analyzed in the open literature. However, there are many other stream ciphers out there: Diamond, Blowfish, RC5, etc. My gut feel is that RC4 is probably adequately secure with a 128-bit key; then Apple can dumb down to 40 bits for export approval. After all, they're not likely to build a product which they can't export. What about using a PCMCIA card like the National Semi Persona 100? It includes RSA signatures & verification, Diffie-Hellman key exchange (I think) and single DES; future versions will include 3DES and IDEA. Hardware encryption is fast, fast, fast. Don't forget AT&T's recent announcement of a similar product which does 3DES. One MCIP reader proposed just using PGP: RSA the session key and send it along. IMHO Diffie-Hellman is a better way to do this. Rather than using the PGP metaphor, where RSAing the session key allows you to send the session key as part of the message, DH allows you to establish the session key over an insecure channel, then start sending messages. - -Paul - -- Paul Robichaux, KD4JZG | Good software engineering doesn't reduce the perobich(a)ingr.com | amount of work you put into a product; it just Not speaking for Intergraph. | redistributes it differently. ### http://www.intergraph.com ### -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzEFkKfb4pLe9tolAQEtEAP/bxEHw+fwPaJJPyHaRRtuZqlxmzvEyD+w 5cmB9c75gzkY9SpSSLkbtawwUjCCiKynMAX76uSRaDRkVeTILelJ3gvdguRMS3Id MYQI162mPvCN+lTvsMoXVJAdZzC14WE9JE0t9FC+ovYE8M+/yZ16EGEnvtWbnNYQ pO8GkvNpR+g= =n3fX -----END PGP SIGNATURE-----

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

Re: Fundies!
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Oops. That's what I get for not finishing my mail before firing off those zingers... Tim, as usual, said it better than I could. I don't retract the following, I just apologize for it's redundance.. >At 10:33 AM 11/17/94 -0800, James A. Donald wrote: > >>This thread is totally irrelevant to cypherpunks. > >I'm beginning to understand Mssrs May and Hughes' peeves about this kind of >cruft. > >Could you folks please take this discussion offline. > >Thanks, >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

info
by Luis Agustin Perez 17 Dec '03

17 Dec '03

I recently read an atricle in HT magazine called cyberbucks. I was wondering if you could send me some information on the topic of the article. thanx

1 0

Re: Islands in the Net
by eric＠remailer.net 17 Dec '03

17 Dec '03

From: tcmay(a)netcom.com (Timothy C. May) Language is an example we ought to look at more closely, as both of us have noted. In contrast to the "data structures" we love so much, natural language is a way of creating a more fluid data structure, a more nuanced statement. The version of language though, that I was referring to were formal languages, the stuff of DFA's (deterministic finite automata) and push-down automata. The advantage here is entirely in their formality, in that precise interpretations of a formal language can be made. A great benefit derives from the explicit formulation of the semantic scope of particular representation. A formal language _can_ "mean exactly what I want it to mean, neither less nor more." The social process of creating these interpretations ("meanings") and getting everyone to agree upon them, however, can be tortuous. We in the ASCII world all agree that the number 65 represents the capital letter 'A', but the letter 'A' is a further abstraction, albeit universally shared in the literate world. Interpretations of data structures almost universally share this trait; they are reductions of one abstraction to another. Two major problems about compatibility can be framed in terms of formal languages: the need for well-formed data structures and the coexistence of multiple data structures. The formal language notion of recognition is merely an algorithm for set membership, the set being called the "language". "Is this string of symbols a member of the language or not?" Is layman's terms, the problem is with data corruptions. While everyone knows data corruption is a problem, deciding what data is corrupt and what is not is sometimes difficult; witness the habitual arguments between client and server writers about whose implementation is wrong. Even fairly clear standards like RFC-822 (mail) leave wide holes in interpretation. The second problem is less immediately pressing and ultimately more important. Given a string of bits, what exactly _does_ it refer to? One can pass it through all the recognizers one has, but it may still not be uniquely determined as being a particular kind of data. Compatibility between data of different types will be of vital importance to achieve systemic robustness. Any set of languages, though, can be made compatible by prepending a common language which acts as a dynamic type specifier. Unix has the beginnings of this with its "#!" syntax for picking the interpreter of an executable. The problem with the Unix version of this is that a particular interpretation binary is specified, not an actual language specification. Natural language is often misinterpreted, hence the value of data structures. For example, I'm glad my financial accounting at my stock broker is handled with robust data structues, but I'm also glad to be able to communicate my goals and desires in a natural language. Well, there's someone somewhere who understands both the formal language and the natural language; it can be either oneself or an intermediary. Now the formal language may be quite flexible and understandable and admit synonyms, but the contextual nature of human languages mitigates against their strict interpretation. One of the real-life characteristics of natural language which isn't present in computer systems is a way of correcting misunderstandings. If one person misunderstands another, further conversation can ensue. If the computer interprets a command differently than the commander intended, disaster can ensue. Suppose I want to delete some data and then I change my mind: E: Computer, please get rid of this old correspondence. C: OK, boss, all done. E: No wait, I need one particular series of those back. C: Sorry, all gone. E: What do you mean, "all gone". C: I destroyed them utterly. E: Why? C: You asked. This stuff has been a theme in SF humor forever. I find it highly ironic that the computer industry, so steeped in SF themes, hasn't thought more about how to alleviate this problem. As a very basic example, consider the issue of data persistence. No standard operating system has at a deep level the notion of "backed-up data". The replication and redundancy could take many forms, including tape, network disk, or data haven. This particular issue is going to be an obstacle for the widespread deployment of digital cash. When a disk crash (hard or soft) means that you lose fungible money, either the problem gets fixed or the system doesn't propagate. What's the common theme? Agents. Chunks of code which also have local processing power (brains, knowledge). I don't think that agents have any relation to the problem of mapping natural languages to formal languages. Perhaps you mean something else by this reference. 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. > If steel were like software, there would be a knob on each beam that > allowed you to change, for example, the balance between hardness and > toughness. Knobs mean random knob-twiddling. Actually, such "dynamic buildings" are becoming more common, I hear. Now add knobs to the thermal expansion coefficients, the densities and masses, the rates of oxidation, the stress-strain matrix elements, etc. If materials engineering were like software, we'd have _both_ nanotechnology and everybody living in trees because they didn't crash so often. But the effect is to increase the "state space" which must be tested, and we are led to "testability" and "provable correctness" of programs, two interesting areas of programming. So far we've seen little application of these ideas to Cypherpunks interests. Not unexpectedly, since these apply to all software, not just cryptography software. > The more specific inspiration for the general form of the remailer > syntax is Jon Bentley's theme of "Little Languages". I'm hopeful that the recent interest in TCL, Safe-TCL [...] The "little" in little languages might be taken to mean "Not Turing Complete". His expository language, as I recall, is the language of floating point numbers, which, alternately, is the question "how do you write down a mantissa and an exponent." Another little language would be email addresses -- still not completely standardized, although blessedly mostly so. 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. These two are not the same at all! "Readable on its face" means that you can actually determine _entirely from the front side of the document_ what the instrument says. If there is an inclusion by reference, then it's not readable on its face. If there is a condition external to the instrument, such as a condition of services rendered, then it's not readable on its face, since some event external to the instrument determines its value. "Readable on its face" just means that one knows what is said, _not_ whether one believes it or not. Those actions which turn the note into a lie are called "conversions" as a group, and forgery is just one form of conversion. (Stealing a note is another.) With a naive implementation of Chaum's blind signature, all you have is a string of bits that can be verified only with some public key. Nowhere in the bits themselves is there an explicit representation of how much the bill is worth, what currency it's denominated in, when it expires, who issued it, etc. These signatures alone are not facially readable. 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. Fandom and enthusiasm will only carry so far in prototyping. One of the reasons that the remailers have attracted such interest is that they do something proximately useful. The questions of reliability and utility that are mentioned here really are key to getting more people trying out stuff. Eric

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: 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