December 2003 - cypherpunks-legacy

Re: Nonsense, absolute nonsense... [Fwd: HipCrime and Spam]
by Admin 17 Dec '03

17 Dec '03

At 09:34 PM 9/11/96 -0400, you wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >On Wed, 11 Sep 1996, Admin wrote: > >> >This is an absurd and inaccurate analogy. The mailBot simply pushes >> >*mailto:* tags that people have willingly placed on their public websites. >> >They invite the mail so a more accurate analogy would be that City Hall puts >> >up a public suggestion box and invites comments. The bot then puts one, and >> >only one, unsigned anonymous suggestion into the box. It then goes on to the > >You're sending out messages, inviting people to visit your web site, but >you're using anonymous remailers because... you don't want people to know >who you are? Perhaps he's sending out through the remailers...because he can. Its open to the public. Or perhaps he's trying to get the word out about remailers also, or perhaps no one but he knows why, and why is unimportant. You can always make your remailers a private, pay per use club. Then you could control all the *whys* *whens* and *hows*. >Then why invite them to your site (or even have a site)? It's >like if I sent out postcards to people with no return address saying, >"Please stop by 1313 Mockingbird Lane for snacks and refreshments. Signed, >A Friend". (Note, this is not my real address.) >Only in this case the >postcards don't have any stamps so the people who receive them have to pay >the postage. Which is precisely what you're doing: Sending someone e-mail >costs them time and it often costs them money. These people have invited the email, and the associated expense, by placing a public email-to: button on their public www page. A more acurate analogy, and to the point, would be if a business sends you a postage pre-paid business reply card, that is blank, and invites your comments on the card. They can hardly complain of the expense when people actually send it in, even if they don't like the comments. >Sending it through an >anonymous remailer accomplishes four things: 1) People can't complain to >you to stop sending them mail. Seems anyone who followed the link can complain to the appropriate source. >2) It costs us, the International Secret >Cabal of Anonymous Remailer Operators, time and money for no good reason, >because you are sending anonymous mail and not making yourself anonymous. Didn't see any disclaimers on the remailers requiring a *good reason* to use them. Who would be this Judge of Sufficiently Good Reason? Perhaps you can write an AI piece that can auto-detect good reason from *no good reason*... >3) You're pissing off a bunch of people, and the only ones they can take >their frustrations out on or complain to is us. What is the ratio of *pissed off people* to not pissed off people. Likely less than 0.5% based on how many messages the Cpunks claim went out in a day. >4) It's giving us a bad >rap, man, and that's the *last* thing the remailer net needs now. The saying goes...There is Heat in the Kitchen... > >I could care less about your little applet, or what you have to say; in >the words of Thomas Jefferson, "it neither breaks my leg nor picks my >pocket." Until, that is, you start sending it through my remailer, and >*then* you start picking my pocket. >The remailers of the world don't exist >to provide non-anonymous anonymous advertising, which you could do just as >well on your own sending forged e-mail headers from netcom. Now now... forgery is a no-no. And someone always has the freedom to give up their anonymity whenever they choose. > >Andy Dustman / Computational Center for Molecular Structure and Design / UGA >===== For PGP public key: finger andy(a)neptune.chem.uga.edu | pgp -fka ===== >Sure, the Telecomm Act will create jobs: 100,000 new thought-cops on the net >http://charon.chem.uga.edu/~andy mailto:andy@CCMSD.chem.uga.edu <}+++< <>________________Lowest_Priced_Long_Distance__________________<> ||Long Distance 9.9¢/min |Helping hardworking people || ||9.9¢ Anytime, Anywhere in US! |like yourself pay the || ||Free sign-up, 6 second billing |lowest possible price for || ||http://www.superhot.com/phone |high quality LD service. || <>-----------------------1_303_692_5190------------------------<>

2 1

That Evil Internet, Pt. XXIII
by drose＠AZStarNet.com 17 Dec '03

17 Dec '03

Caught an interesting segment on this evening's PBS news program with Jim Lehrer. Two senators were discussing whether the U.S. should sign the international agreement banning chemical warfare. Sen. Kyl maintains that verification is impossible and that Iraq, Libya, and North Korea will never participate. Sen. Nunn responds that we should sign anyway. Besides, he adds in the non sequitur of the week, anyone can get instructions on how to build chemical weapons on the Internet. I guess the Internet isn't just for pornography and conventional bomb-making advice anymore. Dave Rose

4 3

jury nullification/selection
by Greg Broiles 17 Dec '03

17 Dec '03

Sorry if I was too terse earlier. I hadn't intended to start a big FIJA dustup. I think that government sleaziness is not only useful in a true nullification argument ("he's guilty but you should acquit anyway") but where it reflects on the credibility of testimony and the prosecution's case in general. It's easy to imagine a prosecution which rests on the testimony of people who lie every day (criminally involved informants, jailhouse informants, and undercover cops) and/or real evidence which was gained through the use of subterfuge and trickery (like wiretap/body wire evidence). The idea is to make the government look sleazier and trickier than the defendant(s) and the defense witnesses. If the government's evidence ends up being tainted directly or indirectly by lying, trickery, etc., then the defense can argue "Hey. You can't trust anyone who got up on that stand and talked to you. And if you don't know who to trust and you think everyone's lying, the government's got no case. And if they've got no case, the judge will tell you that you must acquit." So I think that public distaste and discomfort with weirder and sleazier tactics on the part of cops can be (and is) discussed and used and "voted on". "Not guilty" doesn't necessarily mean "innocent", sometimes it means "The prosecution didn't have enough evidence I thought I could trust." And yes, I agree that even mentioning nullification during voir dire will probably get you kicked off of a jury; and I think that's partly because one party or the other will be scared of nullification, and partly because the term "jury nullification" makes people think of FIJA and associated loons. Nobody wants a loon on the jury. (I don't think everyone who argues for nullification is a loon, but some of them sure are - and there's no good way to figure out whether someone's a loon or not in the middle of jury selection.) And I also agree that the jury selection process tends to select away from a true cross-section of society; but the few easily available examples (big trials like OJ or the Menendez Bros. or Wm. Kennedy Smith or whoever) are poor examples because they're not typical. Trials where lots is at stake (death penalty or celebrity defendant or big $ civil trials) tend to have longer processes (which weed out everyone who isn't incredibly boring) but it's not at all uncommon to pick a jury in a morning or in a day or two. In federal court, the judge usually questions the jury instead of the attorneys (which is faster), and may or may not ask questions that the attorneys have suggested. Also, sometimes one side or the other will *want* especially analytical or technical or well-trained jurors. Attorneys want to pick a jury they can persuade, but they also want to pick a jury that can understand their theory of the case. So I guess my point is that while the jury system isn't perfect, it is in some ways a much more direct way to "vote" on how things work in the judicial and law enforcement systems. I think it's more immediately and directly democratic than the electoral system. All of the legal bullshit aside, it's possible to think about trials as a way for people who have some sort of problem (they've been injured or accused of a crime or whatever) to tell a group of uninvolved people about the problem and ask them what the right thing to do is. Yeah, that's really oversimplified, but I think that what juries do is important and that what they do has a political and a moral dimension even if attorneys aren't supposed to talk about it during argument. -- Greg Broiles | "We pretend to be their friends, gbroiles(a)netbox.com | but they fuck with our heads." http://www.io.com/~gbroiles | |

2 1

Jury Nullification = Voting One's Conscience
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 9:18 PM 9/11/96, Brian Davis wrote: >On Wed, 11 Sep 1996, jonathon wrote: > >> On Wed, 11 Sep 1996, Gary Howland wrote: >> >> > > But the public *is* asked to assent to those methods - your chance >>to vote >> > > on them is known colloquially as "jury duty". >> >> But judges have said that Jury Nullification is not acceptable >> legal practice. > >And other judges have said the opposite. And I don't think there has _ever_ been a case of a juror prosecuted/jailed for voting his or her conscience, regardless of jury instructions. Short of explicitly selling one's vote, or discussing the case during deliberations with outsiders (and probably not even then), one is essentially free to vote one's conscience (however foolishly, as the O.J. case showed). And the principle is a good one: jurors should not have to fear prosecution for voting their consciences, regardless of technical details imposed by a judge. And, of course, jurors are not required to give a court their "reasons" for voting as they do. Though I often condemn aspects of the American political and legal system, it is true that an awful lot of things are done right. --Tim May, who served _once_ on a jury (for a speeding case) in 1973, who was called once since then, but not actually called for a jury. (I vote every election, I am duly registered with the DMV, so I wonder why I have only served once in 24+ years of eligibility.) We got computers, we're tapping phone lines, I know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^1,257,787-1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

2 1

[Long] A history of Netscape/MSIE problems
by pgut001＠cs.auckland.ac.nz 17 Dec '03

17 Dec '03

I've been putting together a writeup on problems in web browsers, mainly the history of the Netscape RC4/40 break, random number bugs, and problems with Java, as part of a longer paper I'm doing on crypto from a non-US perspective. A lot of the information in this section of the paper has come from this list, so I thought I'd post it for comment and in case anyone found it interesting (please don't post it to web sites or anything until the paper is actually published). If anyone has anything to add, corrections to make, etc, please let me know. Peter. The Netscape SSL Break and its Implications ------------------------------------------- The Secure Socket Layer (SSL) protocol, after a somewhat shaky start (version 1 was broken within 10 minutes of being unveiled [Hallam-Baker 1996]), and an attempt by Microsoft to promote a similar but competing protocol [Benaloh 1995], has more or less edged out any other protocols to become the standard for securing HTTP sessions (an overview of SSL and various other proposed WWW security mechanisms is given in [Reif 1995a]). SSL uses a combination of RSA and, usually, a proprietary (until it was reverse-engineered, of which more later) algorithm called RC4 to provide confidentiality, data integrity, and authentication. Since it was built into what was by far the most popular web browser, and because of Netscape's policy of giving away the software, it immediately gained widespread popularity. No details on RC4 were published, but the fact that it was designed by a very good cryptographer was enough to reassure most people. RC4 is used in dozens of commercial products including Lotus Notes, a number of Microsoft products such as Windows for Workgroups, Windows 95, Windows NT, and Access, Apple's AOCE, and Oracle Secure SQL. The main criticism of SSL (apart from a few protocol flaws which were fixed in later versions) was the fact that RC4 used a key of only 40 bits, making it susceptible to a brute-force attack. The reason for the 40-bit key and (according to RSADSI, the company that developed RC4) the reason why details on it were kept secret was that these conditions were required under an agreement between the Software Publishers Association (SPA) and the US government which gave special export status to the RC4 algorithm and a companion algorithm called RC2. Implementations of RC2 and RC4 which are restricted to a 40-bit key get automatic export approval provided the implementations work correctly with a set of test vectors supplied by the NSA. Provided the results are as expected, export approval is granted within a week. The weakness of the encryption in US-exportable SSL implementations even led the French government, which normally bans all non-government-approved use of encryption (the "decret du 18 avril 1939" defines 8 categories of arms and munitions from the most dangerous (1st category) to the least dangerous (8th category), the "decret 73-364 du 12 mars 1973" specifies that encryption belongs to the second category, and the "loi 90-1170 du 29 decembre 1990" states that use of encryption equipment must be approved by the French government), to approve the use of Netscape in France [Vincent-Carrefour 1996], presumably because the French government has no problems in breaking it. The first step in attacking SSL was to find out how RC4 worked. Since it was in widespread use, it was only a matter of time before someone picked the code apart and published the algorithm. RSADSI sell a cryptographic toolkit called BSAFE [BSAFE 1994] which contains RC4, and this seems a likely source for the code (the Windows password encryption code is also a good source, and the algorithm can be extracted in an hour or two). The results were posted to mailing lists and the Internet [Anon 1994a]. Someone with a copy of BSAFE tested it against the real thing and verified that the two algorithms produced identical results [Rescorla 1994], and someone else checked with people who had seen the original RC4 code to make sure that it had been (legally) reverse-engineered rather than (illegally) copied [Anon 1994b]. The RC2 code was disclosed in a similar manner in 1996, but after problems with legal threats during the RC4 disclosure process it was handled more formally: First an RC2 implementation was reverse-engineered [Anon 1996], then a specification for the algorithm was written based on the reverse-engineered code [Gutmann 1996], and finally a new implementation based on the specification was written by someone who had never seen the reverse-engineered RC2 code [Vogelheim 1996]. No legal threats were ever issued over RC2. The RC4 code was immediately subject to intense analysis in various cryptography-related fora. RC4 has two parts, the initialization phase, and the random number generation phase used for the encryption itself. An array is initialized to be a random permutation using the user's key. The random number generator then mixes the permutation and reports values looked up pseudorandomly in that permutation. Among various RC4 problems which were discussed are that the likelihood that during the initialization phase small values will remain in small positions in the initial permutation is too high; user keys are repeated to fill 256 bytes, so 'aaaa' and 'aaaaa' produce the same permutation; results are looked up at pseudorandom positions in the array, and if some internal state causes a certain sequence of positions to be looked up, there are 255 similar internal states that will look up values in the same sequence of positions (although the values in those positions will be different), from which it can be shown that cycles come in groups of 2^n, where all cycles in a group have the same length, and all cycles are of an odd length * 256 unless they are in a group of 256; there is a bias in the results so that, for example, the pattern "a a" is too likely and the pattern "a b a" is too unlikely, which can be detected only after examining about 8 trillion bytes; the internal state is not independent of the results, so that with a given result there are two patterns in the internal state that appear 1/256 times more often than they ought to; at least two seperate methods exist for deducing the internal state from the results in around 2^900 steps; and under certain special circumstances the initial byte of the pseudo-random stream generated by RC4 is strongly correlated with only a few bytes of the key. All of these "weaknesses" except for the last one are purely theoretical in nature, and even the last one can only occur under special circumstances (it doesn't affect SSL implementations since they hash the key with MD5 rather than using it directly, which avoids the problem). Overall, the cryptographic community agreed that RC4, when used correctly, was a sound cipher. Unfortunately, due to the US export restrictions, RC4 couldn't be used correctly. Although Netscape negotiated a 128-bit key to protect each session, it sent 88 of those 128 bits in the clear so that only 40 bits of the key were actually kept secret. Now that RC4 was known, SSL became a prime target for attack. An initial attempt at breaking RC4 was made in July 1995 using encrypted data from a Microsoft Access database [Back 1995a]. This attempt involved 89 contributors and took about a week using idle computing time on workstations and PC's, with around 80% of the work being done by the top 19 contributors. Due to logistical problems, human error, and buggy software, the attempt ultimately failed, but the stage had been set for an attack on SSL. On 14 July 1995, an SSL challenge message containing an encrypted (fake) credit card order transmitted to one of Netscapes own computers was posted to mailing lists and the Internet by Hal Finney [Finney 1995a]. The challenge message was independantly broken by two groups, the first to announce success in breaking it was a French researcher using idle time on a collection of 120 computers and workstations over 8 days [Doligez 1995a] [Doligez 1995b]. The 40-bit secret part of the key was 7E F0 96 1F A6, and was found after scanning just over half the key space. The average search speed was about 850,000 keys/s, with a peak of 1,350,000 keys/s. A second group had broken it two hours earlier, but announced their success a day later [Back 1995b]. The event immediately attracted international media attention, including newspaper, radio, and television coverage (although many reports were rather garbled) in France [Munger 1995], Germany [Reif 1995b], Japan [NewsBytes 1995], the UK [Arthur 1995], and the US [Beck 1995] [Sandberg 1995]. A second challenge was posted on 19 August 1995 [Finney 1995b] and an attack by a `Brute Squad' of 201 Internet-connected volunteers began at 1800 GMT on 24 August 1995. The attack involved greatly improved software with automatic communication between client workstations attacking the encryption and a central server which doled out sections of keyspace to search [Brooks 1995]. This setup took 31.8 hours to find the key, 96 36 34 0D 46. Congestion on the server being used to coordinate the attack meant that most of the machines involved were idle for perhaps 3/4 of their available time, so in theory the attack could have been completed in only 8 hours. Both the client and server software was continually upgraded during the duration of the attack. The attacks, which used only unused processing capacity on the machines, were essentially "free", and could easily be mounted using the spare processing capacity available in companies, businesses, universities, and foreign governments. By breaking a brute-force attack into a number of independant sections, as many machines as are needed can be applied to the problem, so that each doubling of the amount of hardware applied to the problem halves the time required to find the solution. Although the total investment will have doubled, the cost per recovered key is kept constant since twice as many keys can now be found in the same time. Another possibility which has been suggested is the creation of an RC4-breaking screen saver for networked Windows machines which performs key searches during the (often prolonged) periods in which machines are left idle. One experiment in performing this kind of attack took 2 weeks using relatively slow 486/50's and Sparc 20's, with noone the wiser that the machines were being used overnight for this purpose [Young 1996]. Another attack involved a networked Windows screen saver where the client software was activated whenever a machine was otherwise idle and communicated its results to a central server on a network with around 100 PC's. By now, breaking the Netscape encryption had become a kind of processor benchmark, with one manufacturer rating the speed of their system based on how long it took to break RC4 - 8 hours on one computer [ICE 1996]. Further improvements to the attack were proposed. The most important one was to move from attacking one message at a time to attacking entire collections of messages. Instead of generating a key and testing it against a single message, it could be tested against 100 messages, so that in average one key could be found in 1/100th the time it took for a single message. Unfortunately in the case of SSL this wasn't possible, since although only 40 bits of key are kept secret, there are still a total of 128 unique key bits for each message, making it impossible to attack more than one message at a time. In effect the remaining 88 bits of key act as a `salt' in the same way the Unix password salt works. However a more simplistic implementation which uses only 40 bits of key could be attacked in this manner. The attacks on RC4 are a prime example of a publicity attack. They were carried out by volunteers using borrowed machine time, noone (apart from Netscapes stock prices) was harmed, and they achieved a great deal of publicity. The intended goal - of proving that the restricted encryption allowed by the US government could be broken - was achieved. This fuelled intense debate within the US about the need to lift the export restrictions in order to facilitate electronic commerce. Virtually every article covering the encryption debate would eventually refer to the ease with which the 40-bit keys of the form used in SSL could be broken (see for example [Ante 1996]). The fact that it was completely uneconomical to mount a criminal attack on 40-bit SSL keys was mostly ignored (except in Netscape press releases). The enthusiasm for Internet commerce, especially commerce protected by SSL, was severely dented, and companies began to adopt a more cautious attitude in deploying commercial services over the net. [Anon 1994a] `David Sterndark' (an alias), "RC4 Algorithm revealed", posting to sci.crypt newsgroup, message-ID <sternCvKL4B.Hyy(a)netcom.com>, 14 September 1994. [Anon 1994b] Anonymous, "`Alleged RC4' not real RSADSI code", posting to sci.crypt newsgroup, message-ID <9409250900.AA17035(a)ds1.wu-wien.ac.at>, 25 September 1994. [Anon 1996] Anonymous, "RC2 source code", posting to sci.crypt newsgroup, message-ID <4ehmfs$6nq(a)utopia.hacktic.nl>, 29 January 1996. [Ante 1996] Spence Ante, "Everything You Ever Wanted To Know About Cryptography Legislation. . .(But Were Too Sensible to Ask)", PC World, May 1996. [Arthur 1995] Charles Arthur, "Internet's 30bn Pound Secret Revealed", UK Indpendent, 17 August 1995. [Back 1995a] Adam Back, "Announce: Brute force of RC4, 40 bits all swept", posting to sci.crypt newsgroup, message-ID <DC08Dz.LwG(a)exeter.ac.uk>, 20 July 1995. [Back 1995b] Adam Back, "Another SSL breakage...",. posting to cypherpunks mailing list, 17 August 1995. [Beck 1995] Alan Beck, "Netscape's Export SSL Broken by 120 Workstations and One Student", HPCwire, 22 August 1995. [Benaloh 1995] Josh Benaloh, Butler Lampson, Daniel Simon, Terence Spies, and Bennet Yee, "The Private Communication Technology Protocol (PCT)", Microsoft Corporation, October 1995. [Brooks 1995] Piete Brooks, "Cypherpunks `brute' key cracking ring", http://www.brute.cl.cam.ac.uk/brute/. [BSAFE 1994] BSAFE 2.1 software, RSA Data Security Inc, 1994. [Doligez 1995a] Damien Doligez, "SSL challenge -- broken!", posting to sci.crypt newsgroup, message-ID <40sajr$sps(a)news-rocq.inria.fr>, 16 August 1995. [Doligez 1995b] Damien Doligez, "SSL challenge virtual press conference", http://pauillac.inria.fr/~doligez/ssl/press-conf.html. [Finney 1995a] Hal Finney, "SSL RC4 Challenge", posting to sci.crypt newsgroup, message-ID <3u6kmg$pm4(a)jobe.shell.portal.com>, 14 July 1995. [Finney 1995b] Hal Finney, "SSL Challenge #2", posting to cypherpunks mailing list, message-ID <199508191525.IAA16294(a)jobe.shell.portal.com>, 19 August 1995. [Gutmann 1996] Peter Gutmann, "Specification for Ron Rivests Cipher No.2", posting to sci.crypt newsgroup, message-ID <4fk39f$f70(a)net.auckland.ac.nz>, 11 February 1996. [Hallam-Baker 1996] Phill Hallam-Baker, "A problem with Navigator's cache -Reply", posting to www-security mailing list, 25 August 1996. [ICE 1996] Integrated Computing Engines, "MIT Student Uses ICE Graphics Computer To Break Netscape Security in Less Than 8 Days", 10 January 1996. [Munger 1995] Benoit Munger, "Cachez ces mots que je ne saurais lire", Le Devoir, 28 August 1995. [NewsBytes 1995] "Netscape Encrypted Data Cracked", NewsBytes, Tokyo, Japan, 18 August 1995. [Sandberg 1995] Jared Sandberg, "French Hacker Cracks Netscape Code, Shrugging Off U.S. Encryption Scheme", The Wall Street Journal, 17 August 1995, p.B3. [Reif 1995a] Holger Reif, "Netz ohne Angst: Sicherheitsrisiken des Internet", c't Magazine, September 1995, p.174. [Reif 1995b] Holger Reif, "Peinliche Panne: Netscape gibt ernsthafte Sicherheitslu"cken zu", c't Magazine, November 1995, p.26. [Rescorla 1994] Eric Rescorla, "RC4 compatibility testing", posting to cypherpunks mailing list, message-Id <9409140137.AA17743(a)eitech.eit.com>, 13 September 1994. [Trei 1995] Peter Trei, "Netscape's SSL security has been compromised", posting to comp.security.misc newsgroup, message-ID <40t4ti$b8s(a)iii1.iii.net>, 16 August 1995. [Vincent-Carrefour 1996] Jacques Vincent-Carrefour, "Autorisation de fourniture et d'utilisation generale de moyens de cryptologie No.2500", 509/DISSI dossier numero 950038, 7 November 1995. [Vogelheim 1996] Daniel Vogelheim, "RRC.2 implementation available", posting to sci.crypt newsgroup, message-ID <4g5u20$e4k(a)news.rwth-aachen.de>, 19 February 1996. [Young 1996] Eric Young, "Bank transactions on Internet", posting to cypherpunks mailing list, message-ID <Pine.SOL.3.91.960409104403.28771C-100000@orb>, 9 April 1996. (In)Secure Internet Electronic Commerce --------------------------------------- After the RC4 attacks, researchers looked for other weaknesses in Netscape. In September 1995 it was discovered that Netscape didn't check the amount of input it was fed, leading to internal buffers being overrun [Green 1995] [Neumann 1995]. This bug also existed in other browsers such as Mosaic and IBM's WebExplorer. By carefully adjusting the data fed to the browser, it was possible to force a victims PC to execute arbitrary code simply by selecting a URL. This problem has occurred in the past in a number of other programs such as fingerd (where it was exploited by the Internet worm [Spafford 1988]), the CERN and NCSA httpd's (as explained below in the section [!!!!]), and recently splitvt, syslog, and mount/umount, leading one exasperated mailing-list moderator to wonder how many more times he'd see this problem [Bloodmask 1996]. The flaw in question can be exploited by ensuring that the code to be executed is located in the URL at a point where it overflows the end of the buffer. A URL can contain almost any data value except for a few characters which have special significance and a binary zero, a restriction which can easily be bypassed by selecting alternative encodings for any instructions which cause problems. The browser stack looks as follows: [Diagram: URL buffer, other data, callers saved program counter] It is therefore possible, by making the URL long enough to overwrite the other data and saved program counter, to force a jump to an attackers code rather than returning to the calling routine, allowing an attacker to force the execution of arbitrary code on the victims machine. Although this exploit is machine and browser-specific, by targetting the most common architecture (Windows on an Intel processor) and browser (Netscape), a reasonable chance of success can be obtained. At about the same time the stack overwrite problem was discovered, a basic flaw was found in Netscape's SSL implementation which reduced the time to break the encryption from hours to minutes. Despite an existing body of literature covering the need for carefully selected random-number generation routines for cryptographic applications [Eastlake 1994] [IEEE 1995] [Robertson 1995], one of which even included ready-to-use code [Plumb 1994], Netscape used fairly simple methods which resulted in easy-to-guess encryption keys [Goldberg 1995] [Goldberg 1996]. It was found that, under Unix, Netscape used a combination of the current time in seconds and microseconds and the process ID of the current and parent process to initialise the random number generator which produced master encryption keys. The time can be determined to a reasonable degree of accuracy from the message being sent, the process ID's can be determined using standard Unix utilities (by people using the same machine that Netscape is running on), or by using other tricks such as the fact the an approximate process ID can often be obtained by observing the output of other network-related programs on the machine, and the parent process ID is often 1 (for example when Netscape is started from an X-windows menu) or close to the process ID. Under Windows the implementation was similarly flawed. The resulting number of values to search are smaller than the number of combinations in a 40-bit key, and much smaller than the number of combinations in the 128-bit key in the export-restricted version. Since Netscape never reseeds its internal random number generator, subsequent connections are relatively easy to break once the first one is broken. The researchers who discovered this problem released a program, unssl [unssl 1995] which would break Netscape's encryption (both the weak exportable version and the strong export-restricted version) in about a minute on an average workstation. Although one of the researchers classed it as "a silly bug", it received large amounts of media attention, including front-page coverage in the New York Times [Markoff 1995] and coverage in the Wall Street Journal [Sandberg 1995] and Daily Telegraph [Uhlig 1995]. Attempts to fix this problem introduced yet more problems. Under Windows the browser and server code, which appear to share the same random number code, don't close some of the file handles they use. While this has no serious effect on the client software (which doesn't run over extended periods of time), it does effect the server, which after a period of time runs out of file handles so that a number of calls related to gathering random data (some of them not apparently file-related) quietly fail, significantly weakening the random-number generation process [RingZero 1995]. The problem of insecure random number generation was not unique to Netscape, and has in the past beset XDM (which generates weak xauth keys), Netrek (a network game which generates guessable RSA private keys), an earlier version of the SecuDE security toolkit (which again generated guessable RSA keys), and Sesame (a european Kerberos clone) which uses it to generate DES keys. Significant security holes are also opened up through the use of Java, which allows arbitrary programs downloaded from the net to run in a (supposedly) controlled environment on a host PC. By breaking out of this controlled environment, Java applets can act as trojan horse programs on the PC, bypassing normal security measures. The consequences of these security problems have been widely reported and include the destruction of data [Clark 1996], the ability to access arbitrary files on the system [Felten 1996b], the ability to forward sensitive information to arbitrary machines on the net (bypassing firewalls and similar measures, since the "attack" comes from a trusted machine inside the security perimeter) [Williams 1996] [Markoff 1996], or even run arbitrary native code on the machine [Felten 1996a] [Hopwood 1996] [Kennedy 1996]. This last class of flaws are the most serious, since they allow any code to be executed on a victims machine. The problem was in the class loading code for the browser and affected all then available browsers rather than just Netscape, and could be carried out simply by a victim viewing a web page containing the hostile Java applet. Java problems can be combined with other attacks such as DNS spoofing (in which a fake address for a target machine is advertised), allowing a Java applet to connect to a normally disallowed target machine since the Java security manager thinks it is connecting to a safe system [Mueller 1996]. Other problems are less subtle, and can crash the browser (and, under some versions of Windows, the operating system as well) simply by connecting to a web page [Ref: Browser-crashing pages]. One report comes to the conclusion that "because of the wonderful power of the Java language, security problems are likely to continue" [Neumann 1996]. These problems are not unique to Java. Microsoft's ActiveX has experienced similar troubles, exemplified by a sample application which shuts down the machine, and even turns off the power on systems which support this functionality [McLain 1996]. The problems extend beyond Java and ActiveX to other kinds of embedded executable content as well. For example the ability to embed macros in documents viewed and downloaded by a browser, in combination with security holes in the browser, allows an attacker to execute arbitrary code on a victims system whenever they view the attackers web page [Felten 1996c]. Although this was subsequently fixed, the solution was to issue warnings for all local files as well as remote downloads, so that after the first dozen or so messages the user was likely to simply automatically click "OK" whenever another warning popped up [Walsh 1996]. In addition a hostile application could access the Windows registry (the system-wide database of configuration options) to quietly disable the warnings. This creates a nice niche for "espionage-enabling" viruses which disable or patch various security features in operating systems or application software to allow later attacks. At least one security organisation already uses such a program, a modified stealth virus, for this purpose. -> Mention that these are all seperate problems, not the same ref over and over. [Clark 1996] Don Clark, "Researchers Find Big Security Flaw In Java Language" The Wall Street Journal, 26 March 1996, p.B4. [Bloodmask 1996] `Bloodmask', "Vulnerability in ALL linux distributions", posting to linux-alert mailing list, 30 July 1996. [Eastlake 1994] Donald Eastlake, Stephen Crocker, Jeffrey Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [Felten 1996a] Ed Felten, "Security Flaw in Netscape 2.02", Risks-Forum Digest Vol.18, Issue 13, 17 May 1996. [Felten 1996b] Ed Felten, "Java security update", Risks-Forum Digest, Vol.18, Issue 32, 13 August 1996. [Felten 1996c] Ed Felten "Internet Explorer Security Problem", Risks-Forum Digest, Vol.18, Issue 36, 21 August 1996. [Goldberg 1995] Ian Goldberg, "Netscape SSL implementation cracked!", posting to cypherpunks mailing list, message-ID: <199509180441.VAA16683(a)lagos.CS.Berkeley.EDU>, 18 September 1995. [Goldberg 1996] Ian Goldberg and David Wagner, "Randomness and the Netscape Browser", Dr.Dobbs Journal, January 1996, p.66. [Green 1995] Heather Green, "Netscape Says Hackers Uncover 3rd Flaw in Its Internet Software", The New York Times, 25 Sep 1995. [Hopwood 1996] David Hopwood, "Another Java security bug", posting to comp.lang.java newsgroup, message-ID <4orf1q$t6f(a)news.ox.ac.uk>, 2 June 1996. [IEEE 1995] IEEE P1363 Appendix E, "Cryptographic Random Numbers", Draft version 1.0, 11 November 1995. [Kennedy 1996] David Kennedy, "Another Netscape Bug US$1K", Risks-Forum Digest, Vol.18, Issue 1422, May 1996. [Markoff 1995] John Markoff, "Security Flaw Is Discovered In Software Used in Shopping", The New York Times, 19 September 1995, p.A1. [Markoff 1996] John Markoff, "New Netscape Software Flaw Is Discovered", The New York Times, 18 May 1996, p.31. [McLain 1996] Fred McLain, "ActiveX, or how to put nuclear bombs in web pages", http://www.halcyon.com/mclain/ActiveX/. [Mueller 1996] Marianne Mueller, "Java security", Risks-Forum Digest, Vol.17, Issue 79 23 February 1996. [Neumann 1995] Peter Neumann, "Third Netscape weakness found", Risks-Forum Digest, Vol.17, Issue 36, 27 September 1995. [Neumann 1996] Peter Neumann, "More Java, JavaScript, and Netscape problems", in "Security Risks in Computer-Communication Systems", ACM SIGSAC Review, Vol.14, No.3 (July 1996), p.22. [Plumb 1994] Colin Plumb, "Truly Random Numbers", Dr.Dobbs Journal, November 1994, p.113. [RingZero 1995] `RingZero', "NEW Netscape RNG hole", posting to cypherpunks mailing list, message-ID <9510080732.AA14015(a)anon.penet.fi>, 8 October 1995. [Robertson 1995] Richard Robertson, "Random Number Generators Draft", IEEE P1363 Random Number Generators Review Group, May 1995. [Sandberg 1995] Jared Sandberg, "Netscape's Internet Software Contains Flaw That Jeopardizes Security of Data", The Wall Street Journal, 19 September 1995. [Spafford 1988] Gene Spafford, "The Internet Worm: Crisis and Aftermath", Communications of the ACM, Vol.32, No.6 (June 1989), p.678. [Uhlig 1995] Robert Uhlig, "Security threat to Internet shopping", Daily Telegraph, Daily Telegraph (paper edition), 3 October 1995, p.12. [unssl 1995] ftp://ftp.csua.berkeley.edu/pub/cypherpunks/cryptanalysis/unssl.c. [Walsh 1996] Mike Walsh, "Microsoft's warning", Risks-Forum Digest, Vol.18, Issue 38, 26 August 1996 [Williams 1996] Eric Williams, "New Netscape 2.0/2.01 Security Issue (Java Sockets)", posting to comp.lang.java newsgroup, message-ID <4jppdt$ake(a)sky.net>, 1 April 1996. [WSJ 1996] The Wall Street Journal, "Princeton Team Finds Bug In Part Of Netscape Program", 20 May 1996.

5 4

Child Porn and Thought Crime
by Chip Mefford 17 Dec '03

17 Dec '03

If it is a crime to posses photograhic child pornograhy, and this crime is tested in court., , Then is it a crime for a sightless person to posses photograhic child pornograhy? If so, than this matter needs to be thought out some more. If no (by test of court, paper is more or less meaningless) than it is thought crime.

3 2

Re: (Fnord) Edupage, 10 September 1996
by jim bell 17 Dec '03

17 Dec '03

>------- Forwarded Message Follows ------- >************************************************************ >Edupage, 10 September 1996. Edupage, a summary of news about information >technology, is provided three times a week as a service by Educom, >a Washington, D.C.-based consortium of leading colleges and universities >seeking to transform education through the use of information technology. >************************************************************ > >TOP STORIES > Wired World Will "Diminish National Sovereignty" >[..] >WIRED WORLD WILL "DIMINISH NATIONAL SOVEREIGNTY" >A leading Clinton Administration official on information security and >cryptography matters says that traditional notions of sovereignty, national >security and warfare will be undermined by the year 2020, when the whole >world is "wired" and e-cash is the norm. 24 years from now? He thinks it'll take that long?!? 24 years _ago_ the 4004 microprocessor barely existed. And if anything, change is accelerating very rapidly. >The result will be less powerful >governments in relation to criminal organizations such as the Mafia and >international drug cartels, Organizations which exist only because of the existence of government... >says Michael Nelson, who adds that organized >crime members are already some of the most sophisticated users of computer >systems and strong encryption technology. In addition, computer crackers >will pose a more significant threat. In response, Nelson advocates >resolving the issue of whether unauthorized access of a computer is an "act >of trespass" or an "act of war," and prosecuting the intrusions accordingly. >(BNA Daily Report for Executives 6 Sep 96 A14) I'd sure like to be able to corner this guy and point out that there are people who believe that _regulating_ the Internet should either be considered an "act of trespass" or an "act of war." And does he want to be punished, or merely stopped? Jim Bell jimbell(a)pacifier.com

2 1

Getting the word "GAK" into common usage
by Jim Ray 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit To: cypherpunks(a)toad.com Date: Thu Sep 12 11:20:55 1996 cypherpunks: As most of you know, I have been trying to bring "our" word, "GAK" into common usage, as opposed to the "key-escrow" Newspeak proposed by some (unnamed) big-government bureaucrat, and unfortunately adopted in most discussions of cryptography policy, (especially those outside this forum) in spite of the true English meaning of the word "escrow." There is a resource called "Infomania," which you can learn about by sending a blank message with the subject "help" to <infobot(a)infomania.com>. The service provides, via email, services that are normally only available to people who have real internet acess (ie, "WHOIS,") but there is also a heavy bias toward humor. Sending it the subject "GEEK," for example, returns the current version of the Code of the Geeks. Sending the subject CHEF with some dry, boring text (such as this message) in the message body returns you a truly hilarious transmogrification. :) Anyway, I have been in contact with Jason Fesler, who administers the site for Infomania [a firm which produces film separations for commercial grade printers and which provides this free service] about putting in a new command, "GAK," which will return to senders whatever the current U.S. govt. "key-escrow" Newspeak bigbrother anti-privacy proposal(s) is/are. (ie. clipper1, clipper2, son of clipper etc.). He has agreed that if we can supply a script or url or gopher page or something of that sort to interface it to, and a person to maintain it whenever the policy changes yet again (the hard part) he will do it. I would, of course, expect a bit of cypherpunkly commentary to accompany the text. Perhaps this information already exists (likely it does) on some page, and if you know where and think it is stable and well-updated, please email me privately, and I will try to put the owner of the site in touch with Jason. I am Bccing him with this message. Thanks for your help. JMR Regards, Jim Ray -- DNRC Minister of Encryption Advocacy "As govt.s grow arithmetically, corruption grows exponentially." -- Ray's Law of official corruption. Defeat the Duopoly! Stop the Browne out. Harry Browne for President. Jo Jorgensen for Vice-president. http://www.HarryBrowne96.org/ http://www.twr.com/stbo ___________________________________________________________________ PGP id.E9BD6D35 51 5D A2 C3 92 2C 56 BE 53 2D 9C A1 B3 50 C9 C8 I will generate a new (and bigger) PGP key-pair on election night. <mailto:liberty@gate.net> http://www.shopmiami.com/prs/jimray ___________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMjgqXW1lp8bpvW01AQF49wP8Ci8D9blF898dNaFsKesX311qT2MO88zr xM11xZ0g1Ui4ahv3yB4jo6qqv4Z9InjNpiOk6wxcsXUPPtn6UNCBOTdos/DCk/SO SSOupiLA48gBHfoCIMN2f/+hGGM4BcuYC5wQ9rgJrTeiY8nQX18hJxKDxujn7z0A pbvTrSRQozY= =rA5a -----END PGP SIGNATURE-----

2 1

Spam blacklist project
by hallam＠ai.mit.edu 17 Dec '03

17 Dec '03

Hi, The following idea just hit me. How about a server which maintained a list of people who don't want to recive SPAM? The idea being that email recpients who don't want SPAM send their email address to the list. A SPAMer who want to check an email to see if it is on the list could then obtain the SHA-Digested list of addresses and remove them from their internal databases. Of course I don't for a moment imagine that this will be 100% effective. Without government regulation there will always be slimeballs who send mail to people who don't want it. The advantage of this scheme is that it would mean that the spam industry can avoid regulation pressure and they can deflect criticism. Meanwhile recipients of unwanted spam have a legitimate beef. Comments? Phill

6 7

Re: Snake Oil FAQ 0.4 [comments appreciated]
by Deranged Mutant 17 Dec '03

17 Dec '03

For those not-yet-in-the-know: I no longer have the time to manage it and asked for somebody (and Matt agreed to) to take the Snake Oil FAQ's care and feeding. Note that this is not cc'd to coderpunks. I don't think it's appropriate for coderpunks. On 16 Sep 96 at 9:56, C Matthew Curtin wrote: [..] > --------------------------- snake-oil-faq ---------------------------- > > Snake-Oil Warning Signs > Encryption Software to Avoid [..] > The Snake Oil FAQ is (to be) posted monthly to cypherpunks, sci.crypt, > alt.security, comp.security, and comp.infosystems. We're targeting those who Does it need to be posted monthly? Better to post pointers to it most of the time, possibly to other places as well (alt.2600 comes to mind...). Perhaps when the first 'non-beta' of this document is released a History could be added. [..] > Different products will serve different needs, and it's rare that a product > will serve every need. (Sometimes a product won't be needed: it may be Nitpick: Hm. Change that to "no product will serve every need". > better to use a utility to encrypt files, transmit them over a network using > standard file transfer tools, and decrypt them at the other end than to use > a separate encrypted utility in some cases.) Or more clearly: is encryption THE feature of the utility, or is it an added feature? It's better to use separate utilities made for that purpose rather than one that tries to do everything. [..] > Key Sizes > > Some ciphers, while currently secure against most attacks, are not > considered viable in the next few years because of relatively small keysizes > and increasing processor speeds (making a brute-force attacks feasible). The Change to "making brute force attacks--that is, trying every possible key--feasible". [..] > Symmetric and Public-Key Lengths With > Similar Resistance to Brute-Force Attacks > > Symmetric Key Length Public-key Key Length > 56 bits 384 bits > 64 bits 512 bits > 80 bits 768 bits > 112 bits 1792 bits > 128 bits 2304 bits That's a controversial comparison. I've read references (from a couple of years ago) saying that a 3k-bit RSA key is as strong as a 128-bit IDEA key. Trying to compare the two (symmetric and assymetric) is like running through a tar pit. > Some Common Snake-Oil Warning Signs > > The following are some of the "red flags" one should watch for when > examining an encryption product > > * Technobabble [..] > A sign of technobabble is a descrption which drops a lot of technical > terms for how the system works without actually explaining how it > works. Often specifically coined terms are used to describe the scheme > which are not found in the literature. Of course, how is an amateur supposed to know if these terms are found in the literature? That was a recurring comment that people sent me when I first posted the FAQ. [..] > Just because software uses to different method of computation Typo! "uses to different method..."? [..] > grounded in mathematical theory. The security is based on problems that > are believed, if not known to be hard to solve. Hm. How about "that are widely believed"? [..] > A OTP system is not an algorithm. It works by having a "pad" of > random bits in the possession of both the sender and recipient. [..] > never again be used. The bits in the pad must be truly random, > generated using a real random source, such as specialized > hardware, radioactive decay timings, etc., and not from an > algorithm or cipher. Anything else is not a one-time-pad. Although it is(?) mentioned below, I'd emphasize here in some way that the users of the OTP generate the key. Somebody else sending you a supposed OTP that he generated is not secure. > The vendor may confuse random session keys or initialization vectors > with OTPs. Explain random session keys and initialization vectors. A glossary at the end of the document would be a good thing. > Sometimes attacks are theoretical or impractical (requiring special > circumstances or massive computing power running for many years), and > it's easy to confuse a layman by mentioning these. Oh yeah. These need to be explained. What I had in mind was timing attacks against RSA or IDEA, or factoring of public keys. > * Keys and Passwords > > The "key" and the "password" are often not the same thing. The "key" "often" not?!? (oops...was that my wording?) They aren't the same, though often they are confused in snake oil. [..] > If there's a third-party utility that can crack the software, > avoid it. > > If the vendor claims it can recover lost passwords (without using a > key-backup or escrow feature), avoid it. > > If there is a key-backup or escrow feature, are you in control > of the backup, or does the vendor or someone else hold a copy > of the key? That is, if you lose the key, you don't want a third party to have as much a chance to recover it as you do. [..] > > If the vendor is unaware of export restrictions, avoid the software: > the vendor is not familiar with the state of the art. Also... if the vendor does not understand export restrictions, avoid the software. I'm thinking of a certain snoil-vendor who said 128-bit IDEA keys were'nt secure since they could be exported. > Because of export restrictions, some legitimate (not-Snake Oil) > products may have a freely exportable version for outside of the USA, > which is different from a separate US/Canada-only distribution. Also Such exportable versions are not as secure, of course. [..] > Other Considerations > > Interface isn't everything: user-friendliness is an important factor, but if > the product isn't secure then you're better off with something that is > secure (if not as easy to use). > > No product is secure if it's not used properly. You can be the weakest link > in the chain if you use a product carelessly. Do not trust any product to be > foolproof, and be wary any product that claims it is. I wanted to add some sort of 'non-guru hacks' to test a product. One example might be to actually examine 'encrypted' files to see if they are really encrypted. (I'm thinking of the AMG archiver, which only encrypted the CRC; CODEC archiver also only encrypted the CRC is a file is not compressed.) Thanks again for taking over the FAQ. A good job! Rob --- No-frills sig. Befriend my mail filter by sending a message with the subject "send help" Key-ID: 5D3F2E99 1996/04/22 wlkngowl(a)unix.asb.com (root@magneto) Send a message with the subject "send pgp-key" for a copy of my key.

1 0