December 2003 - cypherpunks-legacy

Magic Money
by EWilhem＠aol.com 17 Dec '03

17 Dec '03

Where do I get the software, Please E-mail me at roger12(a)cam.org. I'd like the evaluation software.

2 1

Crypto-law etc
by Chuck McManis 17 Dec '03

17 Dec '03

The longer I follow the crypto "debate" the more I begin to understand what must have been the real intent behind the 2nd amendment of the constitution. If the White House can get crypto code defined in the true legal sense (that is backed up by case law) as a munition, do US citizens then have a constitutional right to "bear" it? Just curious, --Chuck

3 2

on topic!!
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

PM and TCM frequently debate about what is relevant on this list. I have sometimes commented on this. in fact PM's conservative stance to relevance, and TCM's more liberal one, and the tension between the two goes back to list origins. this is a highly inflammable topic, and I am surely going to get my eyebrows toasted for saying *anything*, however I would like to say a few things: if there were two key elements here, these conversations would probably largely go away (instead of continually reappear) - an unambiguous charter - an active moderator unfortunately I suspect that a moderator does exist but he "prefers to remain anonymous" ("pseudonymous"?). imho that is precisely how *not* to succeed as a moderator. PM and TCM are indeed filling a genuine vacuum. when the moderator is AWOL, pseudomoderators fight each other. (oops, the whole idea of a moderator is just not anarchic enough. well, then I suggest everyone just enjoy these repeated, endless displays of public bile and hostility as the basic modus operandii of people who embrace the glory of anarchy. anarchy in action!! but it is more fun to deny them as total delusions and effects entirely attributable to one's enemies..) -- also, another frequent split on this list is of politics vs. coding. frankly I think just having two lists, one dedicated to "cypherpunk politics", the other dedicated to "cypherpunk technicality", would solve most problems. and finally again I suggest as I have in the past that no one other than the moderator really has any authority to say what is or is not relevant. and if you see someone say what is, take it with a grain of salt, or ignore it if you like. a major problem is people defending themselves when they are attacked by someone who says "that's not relevant!!". the problem is the perception of the loss of face. otherwise, what's the point? this is an interesting psychological effect that I have observed even when people use pseudonyms. it seems it is deeply ingrained into human behavior. this list is in fact imho a hotbed of psychological displays. the machismo factor is pretty thick and deep at times too. to all this I suggest one consider the idea that "criticism by a bonehead is as flattering as praise from a genius". (hee, hee) for those who absolutely cannot refrain from trying to yell at other people about relevant postings (judging by the mail, a rather significant percentage) I suggest you quote the *charter* whenever you do so, to demostrate whatever authority it is you think you have. -- anyone who needs moderator lessons should take them from S.Sandfort, an ex teacher who runs cypherpunk meetings involving a lot of childhood psychologies as effectively as humanly possible, IMHO. -- p.s. it appears to me the entrance requirements for cypherpunk membership are to have a 150 IQ and a 75 *EQ*. and that all the arguing and hostility comes from the more uninhibited pathological cases of these people. -- one could in fact have great fun impersonating someone with a grotesquely low EQ on this list and create a tremendous reaction among all the people with equally low EQs, responding to the bait with the same intelligence a fish attacks a wiggling worm. it would be "evolution in action", imho. (hee, hee.)

1 0

Re: DejaNews all over again--a URL for Usenet Searching
by tcmay＠got.net 17 Dec '03

17 Dec '03

[Please don't copy Eugene Volokh <VOLOKH(a)law.ucla.edu> on your follow-ups; I copied him on my original because I had quoted him.] At 10:04 PM 11/6/95, s1113645(a)tesla.cc.uottawa.ca wrote: >Judging by the amount of posting you do here, I was surprised that I only >got 36 listings on your new address (1/3 of which quoted you but not >directly written by you). Either you post more to alt, soc and talk (which >they >don't have) or you use a third address (the second thing I tried was >tcmay(a)netcom.com, even less, though the archive's pretty recent, so that's >expected). I do little posting these days on Usenet. There is almost no sense of "community" there, in the sense of persistent, memorable posters, and in the sense of even _slightly_ having similar goals and aspirations. A vast number of the posts on any topic come from people who just rolled off the turnip truck and who have no interest in learning. >I figured I'd send this to you as a private note, but then I figured >this thing really is scary and has a lot to do with anonymity. >Watch out folks. Litte Brother is saving everything you've ever said on >usenet. Your old posts just won't go away. I've assumed this for many years. One used to be able to buy "Usenet on CD-ROM"...before the volume got to be too high. I've always assumed that archives would be increasingly available, eventually covering the entire history of Usenet, going back to the early 80s, and with tools for tracking the changes in login names over time (so that, for example, Perry's 1984 postings could be easily retrieved). Dossier services are coming, of course. If not legal to operate in the U.S., trivial to locate offshore. ("Employers, we will provide a scan of prospective employers. We can let you know if potential employees have ever posted to alt.drugs, alt.homosexual, alt.deviancy, or alt.cypherpunks. Avoid needless risks.") >(Not that someone who is so open in his views and true name as yourself >would mind, Tim, but I'm certainly happy for my sake, that alt isn't archived >yet. It's bad enough they have rec.) Huh? What makes you think "alt" is not archived? Just because DejaNews doesn't index it doesn't mean it is isn't archived in various places. Paul Robichaux pointed me to another searcher, http://www.excite.com/, which _does_ index the alt groups. I'm sure more are coming, reaching further and further back in time. (At the rate the Net has been expanding, by the time they can archive-and-index the last year of Usenet, they can get the entire history for not much more. I'll bet this happens by the end of 1997.) >Ps. I will of course run searches on every other address that the who >command on majordomo(a)toad.com supplies me with, so watch what you say >ladies, gents and otherwise. ;-> >Get those 'nyms ready. I offered the "Blacknet Dossier Service" a couple of years ago to the Extropians list subscribers. Nick Szabo helped me out by claiming to the list that he had purchased his dossier contents, and was "shocked" by what he found. A number of the Extropian list subscribers were quite perturbed before I told them it was a joke. Then I pointed out to them that there is absolutely nothing which stops such things. --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

MOONLIGHTING BECOMES YOU.... Instan
by rewards＠t-1net.com 17 Dec '03

17 Dec '03

/////////////////////////////////////////////////////////////////////////////// This Message was Composed using Extractor Pro Bulk E- Mail Software. If you wish to be removed from this advertiser's future mailings, please reply with the subject "Remove" and this software will automatically block you from their future mailings. //////////////////////////////////////////////////////////////////////////////// Were sure you will agree this FREE report will reveal money manking secrets so powerful, it could change your life forever !!!! Its never been easier to generate profits. Take this important FIRST STEP For FREE DETAILS send e-mail to: cash(a)answerme.com

1 0

House Report on SAFE
by John Young 17 Dec '03

17 Dec '03

The National Security Committee report on SAFE is available: http://jya.com/hr105-108-pt3.htm (48K) This provides discussion of the Weldon-Dellums amendment and other matters. The Intel Committee report is due out shortly, which is designated Part 4.

1 0

Java insecurity - long - argumentative - you are warned.
by fc＠all.net 17 Dec '03

17 Dec '03

WARNING - THIS MESSAGE CONTAINS INFORMATION THAT MIGHT BE CONSIDERED AS A FLAME BY SOME READERS - IT IS LONG AND TEDIOUS - YOU ARE WARNED! >From the Java Web pages (as combined in Firewalls/BoS): > The language's security features (not just applets): > > (http://java.sun.com/whitePaper/javawhitepaper_6.html#HEADING15) > > 4.2 Security in the Java Environment > > Security commands a high premium in the growing use of the Internet > for products and services ranging from electronic distribution of > software and multimedia content, to "digital cash". The area of > security with which we're concerned here is how the Java compiler and > run-time system restrict application programmers from creating > subversive code. But not non-subversive code? Sounds like a value judgement to me. Subversive code is not otherwise defined in these documents. > The Java language compiler and run-time system implement several > layers of defense against potentially incorrect code. Is incorrect code subversive? Vica versa? Does Java provide defenses against my code not properly calculating numbers? > One of the Java > compiler's primary lines of defense is its memory allocation and > reference model. Simply put, Java does not have "pointers" in the > traditional C and C++ sense--memory cells that contain the addresses > of other memory cells. > > Memory layout decisions are not made by the compiler, as they are in C > and C++. Rather, memory layout is deferred to run-time, and will > potentially differ depending on the characteristics of the hardware > and software platforms on which the Java language system is > executing. The Java interpreter references memory via symbolic > "handles" that are resolved to real memory addresses at run time. Java > programmers can't forge pointers to memory, because the memory > allocation and referencing model is completely opaque to the > programmer and controlled entirely by the underlying run-time system. Just because it is opaque, doesn't mean you can't happen across a valid (but perhaps undesirable) handle. Sounds like a good issue for attack by crypto-types. How do we guess the handle of the disk IO routines? > Very late binding of structures to memory means that programmers can't > infer the physical memory layout of a class by looking at its > declaration. By removing the C/C++ memory layout and pointer models, > the Java language has eliminated the programmer's ability to get > behind the scenes and manufacture pointers to memory. These features > must be viewed as positive benefits rather than a restriction on the > programmer, because they ultimately lead to more reliable and secure > applications. Is the language un-predictable? The same program executes differently each time? A pseudo-random allocation? What is the technique used to implement this, and why should we believe it is in fact secure in some sense. And if so, in what sense? > The Byte Code Verification Process > > What about the concept of a "hostile compiler"? Although the Java > compiler ensures that Java source code doesn't violate the safety > rules, What are these "safety rules"? No reference to them in this document! > when an application such as the HotJava web browser imports a > code fragment from anywhere, it doesn't actually know if code > fragments follow the Java language rules for safety--the code may not > have been produced by a known-to-be trustworthy Java compiler. In such > a case, how is the Java run-time system on your machine to trust the > incoming byte code stream? The answer is simple--it doesn't trust the > incoming code, but subjects it to byte code verification. > > The tests range from simple verification that the format of a code > fragment is correct, to passing through a simple theorem prover to > establish that the code fragment plays by the rules--that it doesn't > forge pointers, it doesn't violate access restrictions, and it > accesses objects as what they are (for example, that "InputStream" > objects are always used as "InputStreams" and never as anything > else). A language that is safe, plus run-time verification of > generated code, establishes a base set of guarantees that interfaces > cannot be violated. Wait a minute. If it's so safe, what code can possibly be sent in that would cause a violation? If the prover is so simple, how can it show things (e.g., program correctness) in real-time on a PC that the rest of the world can't show with supercomputers over extended periods? What EXACTLY are these things doing, and why should we believe they are safe? > The Byte Code Verifier > > The last phase of the byte code loader is the verifier. It traverses > the byte codes, constructs the type state information, and verifies > the types of the parameters to all the byte code instructions. > The illustration [see the HTML] shows the flow of data and control > from Java language source code through the Java compiler, to the byte > code verifier and hence on to the Java interpreter. The important > issue is that the Java class loader and the byte code verifier make no > assumptions about the primary source of the byte code stream--the code > may have come from the local system, or it may have travelled halfway > around the planet. The byte code verifier acts as a sort of > gatekeeper. The byte code verifier ensures that the code passed to the > Java interpreter is in a fit state to be executed and can run without > fear of breaking the Java interpreter. So there are byte code sequences that can break the interpreter! > Imported code is not allowed to > execute by any means until after it has passed the verifier's > tests. Once the verifier is done, a number of important properties are > known: > > There are no operand stack overflows or underflows Not so easily proven, is it? > The types of the parameters of all byte code instructions are > known to always be correct Huh? I thought you couldn't have incorrect types. Do they mean that you can have incorrect types but that they are detected by the verifier at load time? > No illegal data conversions are done, like converting integers > to pointers How about legal ones - like converting integers to pointers via case statements? > Object field accesses are known to be legal--private or public > or protected What exactly does this mean? > While all this checking appears excruciatingly detailed, by the time > the byte code verifier has done its work, the Java interpreter can > proceed knowing that the code will run securely. Knowing these > properties makes the Java interpreter much faster, because it doesn't > have to check anything. There are no operand type checks and no stack > overflow checks. The interpreter can thus function at full speed > without compromising reliability. Can computers actually "know" anything? No runtime checking whatsoever. Get past the supposed verifier, and you have free run of the machine. A single verifier bug or inadequacy, and the world is unsafe for electronic commerce. And has the Java code been verified to prove the claimed properties? Against what criteria? Where's the beef? > Security Checks in the Class Loader > > After incoming code has been vetted and determined clean by the byte > code verifier, the next line of defense is the Java class loader. The > environment seen by a thread of execution running Java byte codes can > be visualized as a set of classes partitioned into separate name > spaces. There is one name space for classes that come from the local > file system, and a separate name space for each network source. > > When a class is imported from across the network it is placed into the > private name space associated with its origin. When a class references > another class, it is first looked for in the name space for the local > system (built-in classes), then in the name space of the referencing > class. There is no way that an imported class can "spoof" a built-in > class. Built-in classes can never accidentally reference classes in > imported name spaces--they can only reference such classes > explicitly. Similarly, classes imported from different places are > separated from each other. But they can explicitly reference each other? I can only explicitly open a file called command.com on your PC? > Security in the Java Networking Package > > Java's networking package provides the interfaces to handle the > various network protocols (FTP, HTTP, Telnet, and so on). This is your > front line of defense at the network interface level. The networking > package can be set up with configurable levels of paranoia. You can: > > Disallow all network accesses > > Allow all network accesses > > Allow network accesses to only the hosts from which the code was > imported > > Allow network accesses only outside the firewall if the code > came from outside Who wants to bet that 99+% of all users configure "Allow all network accesses". Hot Java today is defaulted to this state. > Applet-specific security: (written for the 1.0a3 release of > HotJava(tm)... there will be a rewrite for the 1.0b release when that > occurs. I'm assuming, perhaps incorrectly, that the Netscape > implementation is similar. As I understand it, they licensed the HJ > code from Sun, so I think it's all very close to the truth.) > > (http://java.sun.com/1.0alpha3/doc/security/security.html) > > [ A rehash of the above text, snipped ] > > Security level four: protecting the file system and network access > > HotJava enforces security policies confident that its security > interfaces are secure. In other words, it assumes the other three levels worked properly. If they don't, you're screwed. > The three lower levels of security guarantee > that all local classes, e.g., the file access primitives, are > themselves protected from being supplanted, replaced, or extended by > imported code. You're screwed. > The file access primitives implement an access control list that > controls read and write access to files by imported code (or code > invoked by imported code). The defaults for these access control lists > are very restrictive[*]. If an attempt is made by a piece of imported > code to access a file to which access has not been granted, a dialog > box pops up to allow the user to decide whether or not to allow that > specific access. These security policies err on the conservative side > in order to ensure maximum security. This conservative approach may > make writing some applets more difficult or awkward. By default - ask the user. That's restrictive? Please press the OK button to have our free Lotus update loaded into your computer. > For network security, HotJava provides a variety of mechanisms that > can provide information about the trustworthiness of imported > code. These mechanisms cover a wide range of possibilities. At the > simple end the system can check on the origin of a code fragment to > determine if it came from inside or outside a firewall. At the > sophisticated end of the range a mechanism exists whereby public keys > and cryptographic message digests can be securely attached to code > fragments that not only identify who originated the code, but > guarantee its integrity as well. This latter mechanism will be > implemented in future releases. So today, if the admin specifies the proper IP address ranges when loading Java into each computer in the network, and if no user ever installs Java on their own, "code" downloads from external machines may be stopped - unless the user says OK. > The security policies implemented by the runtime system can be > dynamically adjusted based on the information available concerning the > origin of a code fragment. The Socket class provides such an example. > > The Socket class implements security policies that are adjusted to > reflect the trustworthiness of the code that invoked it, and > transitively, the code that invoked the invoker. The information about > what code began the chain of execution is available to the class in > the form of which namespace contains the invoking code and what > parameters are associated with that class. The class loader puts the > classes it has loaded in a specific namespace, allowing the Socket > class to determine the network host from which a class is loaded. > > Knowing the network host allows the HotJava security mechanism to > determine whether the class originated inside or outside a > firewall. Knowledgable users of HotJava can decide which category of > hosts to trust when loading executable code. How about the more than 99.99% of users who are not knowledgable of HotJava? > For example, the Socket > class can implement the policy of only allowing new connections to be > created that terminate at the host from whence the code was > loaded. This restriction means that code loaded from outside a > firewall cannot connect to other machines on the net behind the > firewall. Unless that machine acts as a gateway for further processing. > Code that comes from more trusted sources can be allowed > more freedom to make connections to other machines. As an additional > defense against untrusted sources HotJava's security can be set to > prevent any code from being loaded. The level of security is > configurable by HotJava users. The user dictates the security policy. Any user in your site can potentially, through error or omission or intent, open up a hole to your entire network by accidentally pressing the OK button one time or by setting a configuration parameter incorrectly. And your firewall will not save you. ASBESTOS SUITS MAY NOW BE REMOVED - FLAME OFF. P.S. When: Tuesday, November 7, 8AM Where: The Hilton, Washington D.C. (the CSI conference) The talk: 50 Ways to Attack Your World Wide Web Systems If you want a chance to heckle - be there. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

3 2

Re: Crypto++, Cpunk Icons, list noise
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

On Sat, 4 Nov 1995 don(a)cs.byu.edu wrote: > An anonymous complainer writes: > > >Well, Perry, my opinion is that there is far too much noise on this list > >as it is. I have already seen my words drowned out by bellyaching over > >next to nothing. > > POT-KETTLE-BLACK. > > Also, since nothing you've written (in your commentary, as opposed to > anonymous announcements or releases that most people use anonymity for > here) indicates that you're using anonymity for any particular reason, Hmmm, I'm not sure that anyone has an inherent right to question WHY a person seeks moments of anonymity or privacy. I don't believe that anyone should be placed on the defensive, for *choosing* to maintain some semblance of a personal life, or wishing to maintain some illusions that they might still have some shred of personal privacy left. Hopefully, we can still leave a man with his dignity. I should not have to defend my right to present my ideas as I believe are appropriate to the circumstances. My choice to present the idea, that an entire economic sector needs to carefully reevaluate their strategic choices, and their discovered hidden security attitudes -- will stand or fall strictly on its merits. The debate is not advanced in any way by attaching a reputation to the question. Like any other person, I have my skeletons, and I have my regrets. I certainly have unfinished, unresolved, issues that I need to tend to. In that sense, I am no different than any other man. I also realize that ultimately, I'll have to come forward from behind the veil of secrecy which is provided to me. This I will do, after I have reconciled my own security considerations. Please allow me the boundary and dignity to choose when, where, and in what form I choose to reveal myself. That inherent right, should be extended to any man, and no man should be called to account for his desire to maintain his personal privacy, no matter how arbitrary his reasons. Especially when he comes forward to challenge Goliath. > please stop so people can killfile you. Or send it from a nym at > alpha.c2.org. I mean, the NSA has your real name anyway, what's the > point... At this time, I don't feel that a bi-directional private communications channel is needed. I have no need for a "nym". People who need to contact me, can. People who would like to know a bit about me, can. Netscape has my address. So does AT&T. And reputations aren't pertinent. (Although, I will say, that the disappearing here-again, gone again, internet draft at ds.internic.net is simply childish, and I'm certain that it was just routine "file maintenance" that caused the flicker.) The ball isn't in my court, it's in theirs. Netscape and AT&T are some of the primary parties who will have to take the hit for the fiasco that they find themselves in. For now, I'll leave my communication channels with them open, rather than letting my mail queue fill more than it already has. Email that is already overqueued. I don't really envy the two companies' position. No one expects to find as significant a security flaw as my anonymous email to this list detailed at this stage of code Burn-In, and I don't take any pleasure in facing the unenviable task of informing ANY party that a Trojan Horse has been engineered into the fabric of an existing globally installed code base. No one does. And as the messenger, I (hope) I don't have anything to fear, from the NSA or any other foreign group that would seek to pursue its own agenda within the borders of sovereign Canada. I really don't think that the NSA is "evil incarnate", as some list subscribers do. They have their intelligence and know how to use it. Usually, they use it prudently. If I did have any worries about the NSA, then I might take some elementary precautions. I certainly wouldn't have my terminal screen pointing towards the twelve odd feet of open glazing that sits behind me, as I currently do. Privacy can't simply be reduced to "a desire to hide from the NSA", just as security isn't something which is simply provided by licensing from RSA. Look to the message rather than the messenger. Alice de 'nonymous ... ...just another one of those... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.

4 5

SSZ status test [No Reply]
by Jim Choate 17 Dec '03

17 Dec '03

SSZ Status Test No Reply No Repeat

1 0

Re: ecash remailer
by David K. Merriman 17 Dec '03

17 Dec '03

>Hal writes: >[suggesting a problem with Ed the Currency Cleaner] >> What about this, though: Alice did not mean to pay Bob, but rather >> Charlie, and Bob stole the coins. He launders them through Ed's >> service. Charlie never got the cash, and Alice complains to the bank >> that the coins were stolen. The bank says, fine, we can identify the >> perpetrator, let's see... it's Ed. Ed is now charged with theft and >> has an expensive and uncertain legal experience ahead of him. > >Jumping in hastily: > >It seems to me that Ed faces a larger problem if the above scenario turns >out to be a viable attack. Consider the following sequence: Alice and >Charlie decide to get some (payee-anonymous) currency laundromat in hot >water. Alice (payer-anonymously) washes some coins at the laundromat. >Con-man Charlie claims he didn't get paid for some fictional transaction with >Alice. Alice complains to the bank, and the rest proceeds as before. The >Alice-frames-Ed situation is functionally equivalent to the Bob-robs-Charlie >situation from the bank's perspective. > Wouldn't the ability to have the bank prove that the coins were 'cashed' make this all null and void? The only way this would work would be if Charlie is willing to completely forego cashing in the coins, *ever*. Should he cash them in later, Ed would seem to have grounds for suspicion/complain. Dave Merriman This is a test (3 UUE lines) of the unconstitutional ITAR - 1/713th of the PGP executable. See below for getting YOUR chunk! ------------------ PGP.ZIP Part [015/713] ------------------- M=$<(&L`#*IPP",(G6(,,S,`P](<2RWU96XCW86/JBYV8A\D8@X'HB_9H#&\X MX'PCUB.,13B"X8`R?^J-:UB.M_`U\>[#)BS&5$0C,Y#^1CS>1`\T1QTXX6!3 M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/ <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> My web page: http://www.geopages.com/CapitolHill/1148

1 0