December 2003 - cypherpunks-legacy

sufficantly advanced software...
by a2＠ah.com 17 Dec '03

17 Dec '03

...is indistinguishable from a bug. Sufficantly advanced hacking.... ...is indistinguishable from a bug. : The Cypherpunks list has been wiped somehow...everyone was unsubscribed. Send mail to majordomo(a)toad.com with "subscribe cypherpunks" in the subject and as the first line of the message. If you are not on the cypherpunks list, or if you get multiple copies of this message, please ignore it... Mike -a2

1 0

Re: i
by lefty＠apple.com 17 Dec '03

17 Dec '03

> Some nobody writes > > >should you be interested in congratulating jim nalbandian for his > >recent well thought out and highly intellectual contributions to the list > >feel free to contact him personally > > and then treats us to what he purports to be Mr. Nalbandian's phone > number and address. ... The same goes for anyone who would attempt > to _use_ this information. > >Why? A phone call in time saves nine flames. Perhaps he's not a jerk >in person or on the phone? > >My wife is accrediting a potential LaLeche League Leader whose writing >style is very dry and unemotional. They just met in person this >weekend and she's not that way at all in person. > >So yes, give the guy a call and see what's up with him... > >If you care, that is. I harbor grave doubts as to whether this is what the original poster intended. If anyone cares to take it upon themselves to find out Mr. Nalbandian's phone number to have a chat with him, they're certainly entitled to do so. I continue to feel that posting his phone number and address to the mailing list in this fashion constitutes incitement to harassment and invasion of privacy. -- Lefty (lefty(a)apple.com) C:.M:.C:., D:.O:.D:.

1 0

MIT Announces PGP 2.5
by Jeffrey I. Schiller 17 Dec '03

17 Dec '03

Beta Test Release of PGP version 2.5 May 9, 1994 The Massachusetts Institute of Technology announces the distribution of PGP version 2.5, incorporating the RSAREF 2.0 cryptographic toolkit under license from RSA Data Security, Inc., dated March 16, 1994. In accordance with the terms and limitations of the RSAREF 2.0 license of March 16, 1994, this version of PGP may be used for non-commercial purposes only. PGP 2.5 strictly conforms to the conditions of the RSAREF 2.0 license of March 16, 1994. As permitted under its RSAREF license, MIT's distribution of PGP 2.5 includes an accompanying distribution of the March 16, 1994 release of RSAREF 2.0. Users of PGP 2.5 are directed to consult the RSAREF 2.0 license included with the distribution to understand their obligations under that license. This distribution of PGP 2.5, available in source code form, is available only to users within the United States of America. Use of PGP 2.5 (and the included RSAREF 2.0) may be subject to export control. Questions concerning possible export restrictions on PGP 2.5 (and RSAREF 2.0) should be directed to the U.S. State Department's Office of Defense Trade Controls. Users in the United States of America can obtain information via FTP from net-dist.mit.edu in the directory /pub/PGP. *** Beta Release Note -- May 7, 1994 *** Today's release of PGP 2.5 is a beta test release, designed to permit users to familiarize themselves with the program and to give us feedback before we make the final release. This version of PGP2.5 has been tested on the following platforms: MSDOS, Sun381i, Solaris 2.X, Ultrix 4.X, Linux, RS6000, HP/UX Over the next few days, we will be testing PGP2.5 on a variety of other systems and collecting bug reports from this release. Please send bug reports to pgp-bugs(a)mit.edu. If you obtain a copy of this beta release code, please keep checking http://web.mit.edu for the announcement of the final release, so that you can update your copy of PGP2.5. We expect the final release to occur within a week. *** To Get PGP2.5: The directory where PGP2.5 is located is hidden. To get it you need to telnet to "net-dist.mit.edu" and login as getpgp. You will be asked to confirm that you will abide by the terms and conditions of the 3/16/94 RSAREF 2.0 license. The license is in the file "license.txt" in /pub/PGP on net-dist.mit.edu.

1 0

List crash/deleted?
by Mike Ingle 17 Dec '03

17 Dec '03

What happened? 1: A software bug ate the file. 2: Someone hacked toad and deleted everyone. 3: Someone obtained a list of members and forged unsubscribes from everyone. Anyone know for sure? If it was forged unsubscribes, the sendmail logs should show where it came from... Some people have asked about the message I sent out. That was sent to everyone who posted in the last two weeks or so. I had those posts in files and used the from: lines as a distribution list. --- Mike

1 0

Clipper: Govt. Monopoly in the Making - Ineffective Law Enforcement
by Stanton McCandlish 17 Dec '03

17 Dec '03

Date: Mon, 9 May 1994 10:09:02 -0600 From: clewis(a)ils.nwu.edu (Charles Lewis) [according to the author, this may be redistributed at will; for print publication, best contact the author.] The Clipper Chip: Government Monopoly in the Making or Ineffective Law Enforcement Charles Lewis <clewis(a)ils.nwu.edu> 2/26/94 On April 16, 1993, the White House released an official announcement of a new encryption technology called the Clipper Chip. Developed by the National Security Agency (NSA), and implemented by the National Institute for Standards and Technology (NIST), the Clipper initiative was intended to satisfy the private sector's need for secure encryption of data, specifically telephone communications, and at the same time allow law enforcement agencies to tap into these encrypted communications when such actions were approved by the Attorney General. The needs of private industry for secure lines of communication have long been left unfulfilled, primarily because of obsolete legislation that considers encryption algorithms to be a munitions for export purposes. For fear of the potential uses of such algorithms in the wrong hands, the export of technology implementing said algorithms has been virtually impossible. Industry leaders have been reluctant to incorporate encryption into their products because munitions laws would require that the versions made for export would have to be significantly different from the ones sold for domestic use. Meanwhile, industrial espionage remains a significant risk for many private companies. The government maintains that introducing secure encryption for public use could have disastrous effects for law enforcement agencies. "Unfortunately, the same encryption technology that can help Americans protect business secrets and personal privacy can also be used by terrorists, drug dealers, and other criminals," (The White House, Office of the Press Secretary, April 4, 1994). The Clipper initiative was meant to satisfy both the needs of the public sector for privacy, and the needs of law enforcement agencies to conduct legitimate electronic surveillance. To this end, the government proposed the controversial Escrow Encryption Standard (EES), of which Clipper is the first implementation. The concept is simple: Clipper will provide encryption of telephone calls between two Clipper equipped phones. This encryption will be unnoticeable at either end of the connection, but the signal in between will be scrambled to prevent monitoring by unauthorized parties. The scrambled signal can be decoded by using two data 'keys,' each held by a different government agency and released only when the Attorney General approves a request for them. By using this back door in the encryption algorithm, law enforcement agencies will still be able to conduct surveillance. Following the Clinton Administration's announcement of EES, there were concerned responses from many industry leaders and organizations. The primary cause for their anxiety was the power of the government to override the encryption provided by Clipper. This was defended as being a trade-off necessary for the compromise between the availability of encryption to the public and the needs of law enforcement agencies to effectively do their jobs. EES proponents argue that it does not make it any easier to obtain approval for electronic surveillance. The issue of whether the government can be trusted to hold the keys to this system is wide open for debate. Essentially, the government is asking us to trust them in this issue, and many aren't sure that this is wise or necessary. These arguments have far reaching implications for the future of personal privacy in America. It is very important for Americans, both in and out of the government, to consider how these issues affect us all. In the case of the EES, however, there are much more clear cut reasons why this initiative is both ineffective in satisfying the purposes for which it was devised, and damaging to those who would develop or use encryption. Even if we are to trust that the government is acting in our best interests by allowing law enforcement agencies to compromise the encryption standard, and even if we trust that the EES will provide adequate protection of the keys that can be used to bypass this encryption, many have asked just how effective the algorithm implemented in Clipper, called the SKIPJACK algorithm, is in the first place. The answer to this is impossible to ascertain first hand, unless you are one of the privileged few who were responsible for the development or testing of the algorithm. Secrecy is necessary in order to preserve the law enforcement functions ofs the algorithm. According to the NIST approval of EES, this ensures that no one can develop communications devices which use the algorithm without the law enforcement features (NIST, 2/9/94). That is to say that if the algorithm were made public, it would be no problem for a company to produce telephones which were capable of having encrypted communications with Clipper equipped phones, but would be impervious to decryption by law enforcement agencies, defeating the purpose of the algorithm. This secrecy comes at a cost. There is universal concern about the adequacy of an algorithm which cannot be revealed. In order to allay these concerns, the government had SKIPJACK examined by a panel of independent experts, who found it to be secure. Even so, it is difficult for many to simply take the word of this panel rather than to test the algorithm themselves. Dorothy Denning, a member of this panel, has little patience for outsiders who want in: "Nothing can be concluded from a statement questioning the technology by someone who has not seen it regardless of whether that person is an expert in security," (Denning, 2/9/94). By making this claim, she uniformly ignores the questions of the entire cryptography community. The attitude that no one outside of a government agency or government appointed panel is worthy of developing or testing SKIPJACK is echoed by Stuart Baker of the NSA in defending the secrecy surrounding the algorithm: "There are very few institutions other than government that are willing to devote both the kind of energy and resources that it takes to eliminate the last few bugs in encryption software or machinery," (Fourth Conference on Computers, Freedom, and Privacy, 3/24/94). Denning and Baker would have us believe that there is nothing useful to be had from consulting with the many industry and academic experts doing research in this field. In truth, it has often been the case that innovations in cryptography have come from non-government sources. There are many private companies providing encryption services professionally, as well as computer scientists doing important research in the field. Ignoring the opinions of these professionals not only damages the study of cryptography, but potentially hurts the EES by not taking advantage of what these experts have to offer. Even the sacrifice of a publicly available algorithm for the sake of law enforcement is in vain. Whitfield Diffie of Sun Microsystems, a veteran researcher in cryptography, tells us that "the Clipper system, as it has been described, is not difficult to bypass," (Diffie, 5/11/93). If Clipper chips do become as widely available as the government suggests, it will be possible for them to be used in such a manner as to defeat the law enforcement features of the chip. Also, what is to stop one from simply using a different sort of encryption that does not have the back door that Clipper does? According to official press releases, nothing. Government spokespeople repeatedly state that the use of the Clipper chip is entirely voluntary. But there are some drawbacks to not using it. For one thing, it is expected that the first big customer of Clipper equipped devices will be the government itself. Not only will this create many users of the EES right off, but it will also force companies that do business with the government to fall in line with the initiative. Another drawback to not using the government standard will be the old munitions laws restricting the export of encrypting devices. While the government is planning on loosening these restrictions for products using Clipper, "...the Administration will continue to restrict export of the most sophisticated encryption devices," (White House, Office of the Press Secretary, 2/4/94). It appears that the government hopes to simply squeeze out Clipper competitors economically. There are two possible results of the Clipper initiative. In the first scenario, competing encryption standards will arise. Without the government stepping in to make sure that the Clipper chip is the only form of telecommunications encryption available, this is inevitable. Alternate encryption standards will sell to the segment of consumers who would rather not trust the government to listen in on their phone calls. If this happens, Clipper will become completely ineffective for law enforcement because of the people using encryption that doesn't conform to the EES. At best, Clipper will fail. The only possible way that Clipper can not fail is if U.S. government successfully eliminates competitors selling encryption without a back door. Again, the government has repeatedly stated that this is not part of their game plan. If we are to believe that they will not try to create a Clipper monopoly, the first scenario is the only one possible. On the other hand, if the government does in fact force competitors out of the market using economic and legislative pressures, it would be extremely damaging both for the agencies outside of the government which work in the cryptography field, and for individuals using cryptography. The NSA would become the only agency in America with access to the workings of the system which the entire industry would be dependent upon. Additionally, only the NSA would have a say in keeping the EES competitive by incorporating new advances in encryption. Because of this choke hold, private research and innovation in this field would be brought to a halt. Either the U.S. government is prepared to take draconian measures to ensure that the EES is used universally, or the Clipper chip will be unable to keep the phone tapping business alive in the Information Age. The fact that these are the only possible outcomes is reason enough to oppose the Clipper initiative. Glossary Escrow Encryption Standard (EES): The encryption standard proposed by NIST, which has a back door accessible by keys held in escrow by government agencies. Clipper: The first implementation of the EES. This chip will be used in telecommunications devices. SKIPJACK: The encryption algorithm used in the EES. NIST: National Institute of Standards and Technology. Part of the Commerce Department. NSA: National Security Agency CPSR: Computer Professionals for Social Responsibility EFF: Electronic Frontier Foundation Sources Computer Professionals for Social Responsibility (CPSR). Computer Professionals Call For Public Debate on New Governement Encryption Initiative, April 16, 1993. Denning, D. Re:Campaign and Petition Against Clipper, (open letter on the Internet) February 9, 1994. Department of Commerce (DOC) National Institure of Standards and Technology (NIST). Approval of Federal Information Processing Standards Publication 185, Escrowed Encryption Standard (EES), February 9, 1994 Diffie, W. The Impact of a Secret Cryptographic Standard on Encryption, Privacy, Law Enforcement and Technology (congressional testimony), May 11, 1993. Electronic Frontier Foundation (EFF). "Initial EFF Analysis of Clinton Privacy and Security Proposal", EFFector Online, April 16, 1993. Fourth Conference on Computers, Freedom and Privacy. Data Encryption: Who Holds the Keys? (panel), March 24, 1994. Jackson, D. and S. Ratan. "Who Should Keep the Keys", Time, March 14, 1994. Markov, J. "Electronics Plan Aims to Balance Governement Access With Privacy", The New York Times, April 16, 1993. Murray, F. "Government picks affordable chip to scramble phone calls", The Washington Times, April 17, 1993. White House Office of the Press Secretary, Statement of the Press Secretary, February 4, 1994. Note: the great bulk of this information came from the following FTP sites: ftp.cpsr.org /cypherpunks/clipper ftp.eff.org /pub/EFF/Issues/Clipper ---- Charles Lewis Every normal man must be tempted clewis(a)ils.nwu.edu at times to spit on his hands, Institute forthe Learning Sciences hoist the black flag, Northwestern University and begin slitting throats. - H.L.Mencken -- Stanton McCandlish * mech(a)eff.org * Electronic Frontier Found. OnlineActivist "In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich Partners, two-thirds said it was more important to protect the privacy of phone calls than to preserve the ability of police to conduct wiretaps. When informed about the Clipper Chip, 80% said they opposed it." - Philip Elmer-Dewitt, "Who Should Keep the Keys", TIME, Mar. 14 1994

1 0

ping
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

This is an obnoxious, bandwidth-wasting test message. Please flame..er..ignore. Jim_Miller(a)suite.com

1 0

PGP 2.5 changes
by Hal 17 Dec '03

17 Dec '03

Below I have included the contents of the file newfor25.doc from the PGP 2.5 beta release which I just grabbed. It says that old (pre 2.3) signatures will not verify under 2.5. That's too bad. Also, key sizes are limited to 1024 bits. Tough luck for people who made bigger ones, I guess. Looks to me like there may still be a market for a non-RSAREF PGP. Anyway, here's the file: Changes to PGP 2.5: ***** MOST IMPORTANT ***** This version of PGP uses RSAREF 2.0, so it's legal in the U.S.! The RSAREF license forbids you to (among other things; see the license for full details) "use the program to provide services to others for which you are compensated in any manner", but that still covers a lot of people. If you want to use it in a commercial or governmental setting, talk to ViaCrypt (2014 West Peoria Avenue, Phoenix, Arizona 85029, +1 602 944-0773). PGP 2.5 should always be distributed with a copy of the RSAREF 2.0 license of March 16, 1994 from RSA Data Security, Inc., so that all users will be aware of their obligations under the RSAREF license. Since the RSAREF license conflicts with the GNU General Public License that PGP was formerly distributed under, the GPL had to go. PGP is still freely distributable, though. (From a copyright point of view; export controls or some other legal hassle may apply.) *** IMPORTANT CHANGE: RSAREF 2.0 can understand only the pkcs_compat=1 formats for signatures and encrypted files. This has been the default since 2.3, so old files should not be too much of a problem, but old key signatures will encounter difficulties. This change will result in a hole being ripped in the "web of trust" as many old signatures are invalidated. Please check your key rings (pgp -kc) and re-issue any signatures that have been invalidated. PGP by default offers to remove such signatures. Even if you leave them in, they are not trusted. Another RSAREF limitation is that it cannot cope with keys longer than 1024 bits. PGP now prints a reasonably polite error message in such a case. OTHER CHANGES: The support files are thinner. The various contrib directory utilities have not been updated since 2.3a, and since the PGP developers know how annoying it is to have people using an ancient version and complaining about a bug in a program that was fixed a year ago, they have been omitted rather than annoy the contributors in this way. Also, the language translation file, language, is incomplete. The strings that were in 2.3a are there, and some that could be updated without much knowledge of the language, but others that are new to 2.5 are untranslated. The format should be obvious and some tools for manipulating the language traslations are included in the contrib directory. Printed KeyIDs have been incresed to 32 bits, as there were enough keys out there that 24-bit keyIDs were no longer sufficiently unique. The previous 24-bit keyID is the LAST 6 digits of an 8-digit 32-bit keyID. For example, what was printed as A966DD now appears as C7A966DD. The config-file options pubring=<filename>, secring=<filename>, and randseed=<filename> have been added. Hopefully, the uses will be obvious. With these, you can keep keyrings anywhere you like. Of course, they can also be specified on the command line with +pubring= (or abbreviated to +pub=). If the line comment=<string> appears in the config file, the line "Comment: <string>" appears in ASCII armor output. Of course, you can also use this from the command line, e.g. to include a filename in the ASCII armor, do "pgp -eat +comment=filename filename recipient". PGP now enables clearsig by default. If you sign and ascii-armor a text file, and do not encrypt it, it is clearsigned unless you ask for this not to be done. The now enables textmode. Textmode detects non-text files and automatically turns itself off, so it's quite safe to leave on all the time. If you haven't got these defaults yourself, you might want to enable them. All prompts and progress messages are now printed to stderr, to make them easier to find and ensure they don't get confused with data on standard output such as pgp -m output. PGP now wipes temp files (and files wiped with pgp -w) with pseudo-random data in an attempt to force disk compressors to overwrite as much data as possible. On Unix, if the directory /usr/local/lib/pgp exists, it is searched fror help files, language translations, and the PGP documentation. On VMS, the equivalent is PGP$LIBRARY:. (This is PGP_SYSTEM_DIR, defined in fileio.h, if you need to change it for your site.) Also, it is searched for a default global config. This file may be overridden by a local config, and it may not set pubring, secring, randseed or myname (which should be strictly personal) The normal help files (pgp -h) are pgp.hlp or <language>.hlp, such as fr.hlp. Now, there is a separate help file for pgp -k, called pgpkey.hlp, or <language>key.hlp. No file is provided by default; PGP will use its one-page internal help by default, but you can create such a file at your site. On Unix systems, $PGPPATH defaults to $HOME/.pgp. PGP used to get confused if you had a keyring containing signatures from you, but not your public key. (PGP can't use the signatures in this case. Only signatures from keys in the keyring are counted.) PGP still can't use the signatures, but prints better warning messages. Also, adding a key on your secret key ring to your public keyring now asks if the key should be considered ultimately-trusted. Prviously, you had to run pgp -ke to force this check, which was non-obvious. Due to a few people distributing PGP without the manual (including one run of a few thousand CD-ROMs), and the resultant flood of phone calls from confused users, PGP now looks to make sure a manual is somewhere in the vicinity when running to discourage this sort of thing. (If you're getting this warning and need details on how to get rid of it, try pgp -kg.) On Unix, PGP now figures out the resolution of the system clock at run time for the purpose of computing the amount of entropy in keystroke timings. This means that on many Unix machines, less typing should be required to generate keys. (SunOS and Linux especially.) The small prime table used in generating keys has been enlarged, which should speed up key generation somewhat. There was a bug in PGP 2.3a (and, in fact in 2.4 and dating back to 1.0!) when generating primes 2 bits over a multiple of the unit size (16 bits on PC's, 32 bits on most larger computers), if the processor doesn't deal with expressions like "1<<32" by producing a result of 1. In practice, that corresponds to a key size of 64*x+4 bits. Code changes: At the request of Windows programmers, the PSTR() macro used to translate string has been renamed to LANG(). The random-number code has been *thoroughly* cleaned up. So has the IDEA code and the MD5 code. The MD5 code was developed from scratch and is available for public use. The Turbo C makefile was dropped in favour of a Borland C .prj file. You can use makefile.msc as a guide if you need one for a command-line Turbo C.

2 1

Re: ping
by Robert A. Hayden 17 Dec '03

17 Dec '03

On Mon, 9 May 1994, Jim Miller wrote: > This is an obnoxious, bandwidth-wasting test message. Please > flame..er..ignore. ok ) ( ( ( ( ) () @@ ) (( ( ( ( )( @@ ( )) ) ( ( ( ( ()( /---\ (()( ( _______ ) ) )(@ !O O! )@@ ( ) ) ) < ____) ) ( ( )( ()@ \ o / (@@@@@ ( ()( ) /--| |( o| ( ) ) ((@@(@@ !o! @@@@(@@@@@)() ( | > \___| ) ( @)@@)@ /---\-/---\ )@@@@@()( ) | /---------+ (@@@@)@@@( // /-----\ \\ @@@)@@@@@( . | | \ =========______/|@@@@@@@@@@@@@(@@@ // @ /---\ @ \\ @(@@@(@@@ . . | \ \\=========------\|@@@@@@@@@@@@@@@@@ O @@@ /-\ @@@ O @@(@@)@@ @ . | \ \----+--\-))) @@@@@@@@@@ !! @@@@ % @@@@ !! @@)@@@ .. . | |\______|_)))/ . @@@@@@ !! @@ /---\ @@ !! @@(@@@ @ . . \__========== * . @@ /MM /\O O/\ MM\ @@@@@@@. . | |-\ \ ( . @ !!! !! \-/ !! !!! @@@@@ . | | \ \ ) . . @@@@ !! !! .(. @. .. . | | \ \ ( / .( . \)). ( |O )( O! @@@@ . ) . | | / / ) ( )). (( .) !! ((( !! @@ (. ((. . . | | / / () )) )) .( ( ( ) ). ( !! )( !! ) (( )) .. | |_< / ( ) ( ( ) ) (( ) )).) ((/ | ( | \( )) ((. ). ____<_____\\__\__(___)_))_((_(____))__(_(___.oooO_____Oooo.(_(_)_)((_ ____ Robert A. Hayden <=> hayden(a)krypton.mankato.msus.edu \ /__ -=-=-=-=- <=> -=-=-=-=- \/ / Finger for Geek Code Info <=> Political Correctness is \/ Finger for PGP 2.3a Public Key <=> P.C. for "Thought Police" -=-=-=-=-=-=-=- (GEEK CODE 1.0.1) GAT d- -p+(---) c++(++++) l++ u++ e+/* m++(*)@ s-/++ n-(---) h+(*) f+ g+ w++ t++ r++ y+(*)

1 0

shit for brains (fwd)
by lassie!jim%lassie＠netcom.com 17 Dec '03

17 Dec '03

FORWARDED MAIL ------- From: netcomsv.netcom.com!crynwr.com!nelson (Russell Nelson) Date: 09 May 94 Originally To: netcomsv!lassie!jim%lassie (Jim Nalbandian) You have shit for brains. I have to call long distance to get my email. Stop this bs. NOT ONLY ARE YOU PEOPLE IGNORANT BUT YOU ARE GOING TO BE BOMBED -russ <nelson(a)crynwr.com> ftp.msen.com:pub/vendor/crynwr/crynwr.wav Crynwr Software | Crynwr Software sells packet driver support | ask4 PGP key 11 Grant St. | +1 315 268 1925 (9201 FAX) | Quakers do it in the light Potsdam, NY 13676 | LPF member - ask me about the harm software patents do. -- * Spelling errors are intentional and international * Jim Nalbandian netcomsv!lassie!jim%lassie(a)netcom.com Tempe, Arizona, USA N7SZS(a)K7BUC.AZ.US.NA No free man shall ever be de-barred the use of arms. The strongest reason for the people to retain there right to keep and bear arms is as a last resort to protect themselves against tyranny in government. <-------- Thomas Jefferson --

1 0

Re: What's happened to the mail?
by Peter Murphy 17 Dec '03

17 Dec '03

Well, did anyone write "who cypherpunks" to Majordomo? I did. The number of people it contained was about 10 (although it would probably be more than that by now). My guess is that someone (possibly Jim Nalbadian (sic?)) was the culprit. On a related matter, do you need an old (i.e. about 2 weeks old) copy of the cypherpunks mailing list, so as to bring it back to its old glory? ======================================================= | Peter Murphy. <pkm(a)maths.uq.oz.au>. Department of | | Mathematics - University of Queensland, Australia. | ------------------------------------------------------- | "What will you do? What will you do? When a hundred | | thousand Morriseys come rushing over the hill?" | | - Mr. Floppy. | =======================================================

1 0