- cypherpunks-legacy - lists.cpunks.org

Archive of Remailer-Operators List Begun
by L. McCarthy 17 Dec '03

17 Dec '03

I have begun an archive of the remailer-operators list. I've just placed a gzipped file containing the traffic from the last couple of weeks, plus some scattered previous traffic, in //ftp.csua.berkeley.edu/incoming. If/when I learn the ultimate fate of this file, I'll provide further details. -L. Futplex McCarthy

1 0

CP archives?
by erc＠s116.slcslip.indirect.com 17 Dec '03

17 Dec '03

Can anyone tell me where the CP mailing list is archived? Thanks! -- Ed Carp, N7EKG Ed.Carp(a)linux.org, ecarp(a)netcom.com 801/534-8857 voicemail 801/460-1883 digital pager Finger ecarp(a)netcom.com for PGP 2.5 public key an88744(a)anon.penet.fi ** PGP encrypted email preferred! ** Cop: "How many beers have you had tonight, bro?" Suspect: "Seventy." -- from the TV show "Cops"

1 0

<none specified>
by Anonymous 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- My appologies if this has already made it to the list. In article <D2wtJC.C8I(a)freenet.carleton.ca> you wrote: : In a previous posting, Farrell McGovern (ai474(a)FreeNet.Carleton.CA) writes: : > CNN Headline news this morning is running a story saying how the : > Internet is so innsecure that "hackers" can access former VP Quale's : > medical records, number of atomic warheads in a certain state and CIA's : > budget. And all ths is supposedly based upon a "breakthrough" that : > "hackers" have made recently. They say that the Internet will not be able : > to be secure for at least 5 years. : Here's more about it! : : Article #36 (36 is last): : Newsgroups: comp.security.announce : From: ecd(a)why.cert.org (Edward DeHart) : Subject: IP Spoofing Attacks and Hijacked Terminal Connections : Date: Mon Jan 23 16:00:37 1995 : ============================================================================= : CA-95:01 CERT Advisory : January 23, 1995 : IP Spoofing Attacks and Hijacked Terminal Connections : ----------------------------------------------------------------------------- : The CERT Coordination Center has received reports of attacks in which : intruders create packets with spoofed source IP addresses. These attacks : exploit applications that use authentication based on IP addresses. This : exploitation leads to user and possibly root access on the targeted system. : Note that this attack does not involve source routing. Recommended solutions : are described in Section III below. : In the current attack pattern, intruders may dynamically modify the kernel of : a Sun 4.1.X system once root access is attained. In this attack, which is : separate from the IP spoofing attack, intruders use a tool to take control of : any open terminal or login session from users on the system. Note that : although the tool is currently being used primarily on SunOS 4.1.x systems, : the system features that make this attack possible are not unique to SunOS. : : As we receive additional information relating to this advisory, we will place : it, along with any clarifications, in a CA-95:01.README file. CERT advisories : and their associated README files are available by anonymous FTP from : info.cert.org. We encourage you to check the README files regularly for : updates on advisories that relate to your site. : : ----------------------------------------------------------------------------- : : I. Description : : This description summarizes both the IP spoofing technique that can : lead to root access on a system and the tool that intruders are using to : take over open terminal and login connections after they get root access. : We are currently seeing attacks in which intruders combine IP spoofing : with use of the tool. However, these are two separate actions. Intruders : can use IP spoofing to gain root access for any purpose; similarly, they : can highjack terminal connections regardless of their method of gaining : root access. : : IP spoofing : To gain access, intruders create packets with spoofed source IP : addresses. This exploits applications that use authentication : based on : IP addresses and leads to unauthorized user and possibly root access : on the targeted system. It is possible to route packets through : filtering-router firewalls if they are not configured to filter : incoming packets whose source address is in the local domain. It : is important to note that the described attack is possible even if : no reply packets can reach the attacker. : : Examples of configurations that are potentially vulnerable include : - routers to external networks that support multiple internal : interfaces : - routers with two interfaces that support subnetting on the : internal network : - proxy firewalls where the proxy applications use the source : IP address for authentication : : The IP spoofing attacks we are currently seeing are similar to those : described in two papers: 1) "Security Problems in the TCP/IP Protocol : Suite" by Steve Bellovin, published in _Computer Communication Review_ : vol. 19, no. 2 (April 1989) pages 32-48; 2) "A Weakness in the 4.2BSD : Unix TCP/IP Software" by Robert T. Morris. Both papers are available : by anonymous FTP from : : ftp.research.att.com:/dist/internet_security : : Bellovin paper: ipext.ps.Z : Morris paper: 117.ps.Z : : Services that are vulnerable to the IP spoofing attack include : SunRPC & NFS : BSD UNIX "r" commands : anything wrapped by the tcp daemon wrappers - site dependent; check : your configuration : X windows : other applications that use source IP addresses for authentication : : Hijacking tool : Once the intruders have root access on a system, they can use a tool : to dynamically modify the UNIX kernel. This modification allows them : to hijack existing terminal and login connections from any user on the : system. : : In taking over the existing connections, intruders can bypass one-time : passwords and other strong authentication schemes by tapping the : connection after the authentication is complete. For example, a : legitimate user connects to a remote site through a login or terminal : session; the intruder hijacks the connection after the user has : completed the authentication to the remote location; the remote site : is now compromised. (See Section I for examples of vulnerable : configurations.) : : Currently, the tool is used primarily on SunOS 4.1.x systems. However, : the system features that make this attack possible are not unique to : SunOS. : : : II. Impact : : Current intruder activity in spoofing source IP addresses can lead to : unauthorized remote root access to systems behind a filtering-router : firewall. : : After gaining root access and taking over existing terminal and login : connections, intruders can gain access to remote hosts. : : : III. Solutions : : A. Detection : : IP spoofing : If you monitor packets using network-monitoring software such as : netlog, look for a packet on your external interface that has : both its source and destination IP addresses in your local domain. : If you find one, you are currently under attack. Netlog is : available by anonymous FTP from : net.tamu.edu:/pub/security/TAMU/netlog-1.2.tar.gz : MD5 checksum: 1dd62e7e96192456e8c75047c38e994b : : Another way to detect IP spoofing is to compare the process : accounting logs between systems on your internal network. If : the IP spoofing attack has succeeded on one of your systems, : you may get a log entry on the victim machine showing a remote : access; on the apparent source machine, there will be no : corresponding entry for initiating that remote access. : : Hijacking tool : When the intruder attaches to an existing terminal or login : connection, users may detect unusual activity, such as commands : appearing on their terminal that they did not type or a blank : window : that will no longer respond to their commands. Encourage your users : to inform you of any such activity. In addition, pay particular : attention to connections that have been idle for a long time. : : Once the attack is completed, it is difficult to detect. However, : the intruders may leave remnants of their tools. For example, you : may find a kernel streams module designed to tap into existing TCP : connections. : : B. Prevention : : IP spoofing : The best method of preventing the IP spoofing problem is to install : a filtering router that restricts the input to your external : interface (known as an input filter) by not allowing a packet : through if it has a source address from your internal network. In : addition, you should filter outgoing packets that have a source : address different from your internal network in order to prevent : a source IP spoofing attack originating from your site. : : The following vendors have reported support for this feature: : Bay Networks/Wellfleet routers, version 5 and later : Cabletron - LAN Secure : Cisco - RIS software all releases of version 9.21 and later : Livingston - all versions : : If you need more information about your router or about firewalls, : please contact your vendor directly. : : If your vendor's router does not support filtering on the inbound : side of the interface or if there will be a delay in incorporating : the feature into your system, you may filter the spoofed IP packets : by using a second router between your external interface and your : outside connection. Configure this router to block, on the outgoing : interface connected to your original router, all packets that : have a : source address in your internal network. For this purpose, you can : use a filtering router or a UNIX system with two interfaces that : supports packet filtering. : : NOTE: Disabling source routing at the router does not protect you : from this attack, but it is still good security practice to : do so. : : Hijacking tool : There is no specific way to prevent use of the tool other than : preventing intruders from gaining root access in the first place. : If you have experienced a root compromise, see Section C for : general : instructions on how to recover. : : C. Recovery from a UNIX root compromise : : 1. Disconnect from the network or operate the system in : single-user mode during the recovery. This will keep users : and intruders from accessing the system. : : 2. Verify system binaries and configuration files against the : vendor's media (do not rely on timestamp information to : provide an indication of modification). Do not trust any : verification tool such as cmp(1) located on the compromised : system as it, too, may have been modified by the intruder. : In addition, do not trust the results of the standard UNIX : sum(1) program as we have seen intruders modify system : files in such a way that the checksums remain the same. : Replace any modified files from the vendor's media, not : from backups. : -- or -- : : Reload your system from the vendor's media. : : 3. Search the system for new or modified setuid root files. : : find / -user root -perm -4000 -print : : If you are using NFS or AFS file systems, use ncheck to : search the local file systems. : : ncheck -s /dev/sd0a : : 4. Change the password on all accounts. : : 5. Don't trust your backups for reloading any file used by : root. You do not want to re-introduce files altered by an : intruder. : : --------------------------------------------------------------------------- : The CERT Coordination Center thanks Eric Allman, Steve Bellovin, Keith Bostic, : Bill Cheswick, Mike Karels, and Tsutomu Shimomura for contributing to our : understanding of these problems and their solutions. : --------------------------------------------------------------------------- : : If you believe that your system has been compromised, contact the CERT : Coordination Center or your representative in Forum of Incident : Response and Security Teams (FIRST). : : If you wish to send sensitive incident or vulnerability information to : CERT staff by electronic mail, we strongly advise that the e-mail be : encrypted. The CERT Coordination Center can support a shared DES key, PGP : (public key available via anonymous FTP on info.cert.org) or PEM (contact : CERT staff for details). : : Internet E-mail: cert(a)cert.org : Telephone: +1 412-268-7090 (24-hour hotline) : CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), : and are on call for emergencies during other hours. : Fax: +1 412-268-6989 : : CERT Coordination Center : Software Engineering Institute : Carnegie Mellon University : Pittsburgh, PA 15213-3890 : USA : : Past advisories, CERT bulletins, information about FIRST representatives, : and other information related to computer security are available for anonymous : FTP from info.cert.org. : : : : CERT is a service mark of Carnegie Mellon University. : : ------------------------------- : -- : ------------------------------------------------------------------------ : The Information Cowpath is strewn with Meadow Muffins...even the best of : us get the Meadow Muffin Blues every now and then... - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLycwFyoZzwIn1bdtAQH7lQGAqGZx0JupR5oLwwm9wcJkhwZLks3Y1y36 4F9UjunJWFS4sKbts6eLkAT3jakXpTXT =3rGy -----END PGP SIGNATURE-----

4 3

Windows email & pgp
by Joe Turner 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Yes, yet another WinSock E-mail program... Lately, I have been trying out several mail programs for Windows, but have been sorely disappointed by their functionality. I was tired of the annoying "please-send-me-money-now" windows popping up, programs that simply didn't work or worse, didn't work very well. I have used many different mail programs on several platforms, and have yet to find one that I *really* like. Elm would be the closest at this point, but it is annoying and time consuming to have to go through the pains of extracting a mail message, verifying signatures, etc. As a result, I have decided to write a SMPT mail program for Windows 3.x and Windows NT (with WinSock) with PGP incorporated within it. I felt that this is a great opportunity to spread the gospel about an undeniably practical use for encryption for the masses (sound familiar?), somewhat in the vein that PGP was created by Zimmerman, and would like to solicit comments and/or suggestions for what to put in this program. Additionally, any guidance as to what steps I should take to obtain the appropriate licenses, etc., to legally integrate PGP into a program of this type would be greatly appreciated. Here are my specifications/criteria: - Perhaps most importantly, it should work. It should: send, receive, and forward mail messages; allow the user to delete and organize mail messages into folder files; support signature files; support kill files; pipe messages to a user-written application (like setting an mail alias under UNIX). Will support RFC821 and RFC822. Forward files must also be supported. - PGP will be included into the mail program itself, provided I can get the appropriate permissions to legally do so. The mail program will automatically check for PGP keyblocks, encrypted messages, and signatures. Signatures will be automatically checked (unless unfeasible) and the user alerted when a signature does not match. The user will be prompted when keyblocks are in messages, to see if the user would want to add them to his/her keyring. - List management. Due to the high volume of the cypherpunks list, and other lists, I have noticed that I have sometimes been neglected in answering personal e-mail simply because it gets lost in the noise. If you are on a list, and configure it (i.e., signify the cypherpunks(a)toad.com as a mail-list), every message from that list will be marked as such. Mail from a List, but addressed to you from another user (the list is CC:d) will be marked accordingly too. The idea here is to quickly highlight messages that courtesy dictate you respond. I was also thinking of a groupie/worship mode, but I think this is just too much. - Remailer. This will take some more thought, but I would like to give the mail program the ability to forward messages and stomping on the return address, etc., essentially creating a one way remailer. Future versions will support more, but this is a good start. I believe that all of the above mentioned topics have been touched on before, but would like suggestions for this implementation. This windows mail program will be released in the same spirit as PGP, free for academic and non-commercial use; I will not beg for money (but thank-you's and admiration will be accepted as will helpful criticisms). I have already started hashing out the framework, but I will guestimate that it will be roughly 15 weeks before anything usable is produced. Beta testers anyone? -----BEGIN PGP SIGNATURE----- Version: 2.7 iQB1AwUBLyWv9M3mPt807UJ/AQEYOAL/eIhOy5IK0CmDKVl9Kp3lhTHEWmj2zpp1 kzEdD0Ktu4g2N4x+dvUyFEAkY5+mXh1IaexssoP5N7N7grO9NUnL7MST5DHCJQ12 P30DYvfCvPlAc4L41Wxp3pFS25mfI6Zz =UJSx -----END PGP SIGNATURE----- -- Joe N. Turner Telecheck International turner(a)telecheck.com 5251 Westheimer, PO BOX 4659, Houston, TX 77210-4659 compu$erv: 73301,1654 (800) 888-4922 * (713) 439-6597 Finger for me PGP KEY; PGP encrypted mail very welcome.

1 0

anonymous IRC access....
by Vinod Valloppillil 17 Dec '03

17 Dec '03

Is there anyway to get anon irc access? there used to be a way to get it a couple of years ago but I can't find any ways to do it now.... sounds like a problem for cypherpunks.. ------------------------------+----------------------------------------------- Vinod Valloppillil | LibertarianismTelecommunicationsFreeMarketEnvi Engineering/Wharton | ronmentalismTechnologyExtropianismElectronicCa University of Pennsylvania | shInteractiveTelevisionEconomicsPhilosophyDigi vvallopp(a)eniac.seas.upenn.edu | talPrivacyAnarchoCapitalismRuggedIndividualism ------------------------------+-----------------------------------------------

2 1

anon.penet.fi compromise?
by joelm＠eskimo.com 17 Dec '03

17 Dec '03

This was in alt.2600. Comments or verification? --------------------------------- From: will(a)rmii.com (Will Spencer) Newsgroups: alt.2600 Subject: Re: remailer security? Date: 24 Jan 1995 15:48:57 -0700 Steve: The penet database was stolen and posted on Unphamaliar Territories. Will

1 0

Re: Security of UNIX, NT, etc. (Was: Clinton Freezes...)
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

James Donald writes: > > At present it seems to me that unix machines on the internet > > are intrinsicly insecure -- the methods used to secure them > > are a collection of ad hoc patches. For example all > > unix machines are vulnerable to the trojan > > horse attack. Depends on what trojan horse attack you have in mind. Well-designed B1-secure systems can get rid of most of the Trojan Horse attacks by storing the trusted computing base System Low and requiring root to only execute programs at that level, and running all users at higher classifications, like Unclassified. Since users can't write down, they can't hack the TCB, so the main opportunity for Trojan Horses is to trick trusted programs into interpreting data in dangerous ways (e.g. executable editor macros in email, or exploitation of a much smaller set of bugs than usual.) > > Windows NT is supposedly secure. <ftp://sounds.sdsu.edu/somedir/evillaugh.au> And Perry replies: > NT is about as secure as VMS was, i.e. not at all. Its just got > different bugs. As is any system that was designed for purposes other than security and had security added on. (On VMS: The C2-rated VMS systems came out somewhat before the Worms Against Nuclear Killers takeover of a NASA(?) network; it seems that being rated C2 doesn't prevent you from shipping systems with the factory-equipped SYSTEM and FIELD account passwords left alone.) > > Certainly its design makes it possible to write software that is > > intrinsicly secure, rather than creating a particular fix for each > > particular hole. > > You mean, it makes proof of security possible for real programs? > That there is a proof of security available for the NT kernel? > I'd settle for a proof of non-crashing myself. Short of that I'm > unaware of any system that is "intrinsically" secure. I thought there were systems at at least the B3 level, if not A1; Honeywell SCOMP comes to mind. Of course, all those levels are just Orange Book, and extending genuinely provable multilevel security to the multi-computer networked problem was far beyond current research when I was last current on the stuff. (They could update me, but then they'd have to kill me :-).) There was also KSOS, but I don't remember what level of security it reached. There have been B2-rated networks which let single-level machines share a LAN (Verdix VSLAN), and there's a certain level of security you can get running uucp on B1 systems, but bug-free shared networked general-purpose systems are, uh, not very common. And didn't Boeing have a high-rated fiber LAN of some sort? Actually, before networking, MS-DOS was perfectly secure. After all, there's only one User in the universe, and She is allowed to do anything She wants, however ill-advised.... Bill

1 0

analysis of Chaum's MIX continued
by Wei Dai 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Last week I wrote about a way to trace who Alice, using a Chaumian mix, is writing to, by calculating a score for each user based on the number of times the receipt of a message by the mix from Alice is followed by a transmit to the user during the output phase of that batch (I need a name for these occurences... any sugestions?). Does this method actually work? Well, let's see... (Let me note that this method of traffic analysis can be applied to any Chaum type MIX, even if the MIX uses random delays instead of batches. It can even be used on entire MIX-nets, by treating the MIX-net as a single large mix. However, I have to make several assumptions in the following analysis of how well this method works. This doesn't mean that it won't work outside those assumptions, just that I don't know enough statistics to figure out how well it would work in a more general situation. Maybe someone can give me a recommendation for a good statistics textbook?) Let's assume: 1. there is one mix which processes a batch every time it receives a certain number of messages 2. there are N users 3. all users send at most one message to the mix per batch, the probability that he will do so is S (I'm assuming every user sends the same number of messages per unit time on average, many of which can be dummies, and that the timing of these messages are random) 4. all users receive at most one message from the mix per batch, with probability R (R<S or R>S depending on wheather the mix eats more dummy messages than it generates) Alice and Bob (the targets of the traffic analysis) are simply two of those users. 5. In a particular batch, there is a probability Q (Q<=R and Q<=S) that Alice will send a message to Bob. This implies that for each batch in which Alice doesn't send a message to Bob, there is a probability of (S-Q)/(1-Q) that she will send some other message to the mix (which may be a dummy message or a message to someone else). Similiarly, for each batch in which Bob doesn't receive a message from Alice, there is a probability of (R-Q)/(1-Q) that he will receive some other message from the mix. Let T be the length of time (expressed in number of batches) since the start of the traffic monitoring and let M(user) be the total number of times the receipt of a message by the mix from Alice is followed by a transmit to user during the output phase of that batch. Note that the distribution of M is a binomial distribution B(T, R*S). This means: mean of M = T*R*S standard deviation of M = sqrt(T*R*S*(1-R*S)) On the other hand, M(Bob) = T*Q + T(1-Q) * ((S-Q)/(1-Q)) * ((R-Q)/(1-Q)) which simplifies to: M(Bob) = T * (Q + (S-Q)*(R-Q)/(1-Q)) Now, we can calculate a z-score for M(Bob) by subtracting from it the mean of M (this difference simplifies to T*Q*(1-S)*(1-R)/(1-Q) ) and dividing the difference by the standard deviation. We can then find the standard normal probability p(z) associated with the z-score, and finally multiply 1-p(z) and the total number of users (N) to find how many users can be expected to have a larger M than Bob. Let's call this number A. In conclusion: T*Q*(1-S)*(1-R)/(1-Q) A = N * (1 - p ( ------------------------- ) ) sqrt(T*R*S*(1-R*S)) It seems that as long as Q>0, S<1, and R<1, A converges to 0 as T increases. This means under the above assumptions, Bob will eventually be traced out if these 3 conditions are met. Wei Dai P.S. If there aren't any serious mistakes in the above analysis, I may produce a table showing how long it would take for A to fall below 1 for various values of Q, R, S, and N. Is there any interest in this? For now, I've attached an Excel spreadsheet so you can try plugging numbers into the above formula. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLyW/fzl0sXKgdnV5AQHQ/gP+LF/P19djHH5UpXfNQWPsljRTFZv9Bi/S nHJZKVOHC+T5b4/JLHIbNMbH5xRiM4wKHmmpdAoqNRBfWQm+nlikXnuwXJYZemM3 OxAEPLHflMby6SRvrtvT5r+ajm1GVqgYc2JE4Dyz5zBNqBlto1DG0KFK+1MNdYEQ CDUAK5GndnU= =qRUF -----END PGP SIGNATURE----- This message contains a file prepared for transmission using the MIME BASE64 transfer encoding scheme. If you are using Pegasus Mail or another MIME-compliant system, you should be able to extract it from within your mailer. If you cannot, please ask your system administrator for help. ---- File information ----------- File: mix-anal.xls Date: 24 Jan 1995, 18:51 Size: 14848 bytes. Type: Binary

1 0

Re: LOCKSMITH'S GUILD WANTS L
by doumakes＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- tcmay(a)netcom.com (Timothy C. May) wrote: > Again, I'm not claiming anything about PGP making conventional doctors > obsolete. Just the increased freedom of a wide range of services to be > negotiated electronically, without benefit of official guild approvals. > > (This is an actual concern the professional organizations have. They worry > about online medical diagnoses, about "unlicensed" consultants, and about > data bases over which they have no jurisdiction.) I certainly agree with your implication, that professional groups can and sometimes do use licensing to restrain trade, with an eye toward feathering their own nests. But I don't buy your other implication, that it is a Good Thing to unleash the unlicensed. Licensing serves, or should serve, a public good under the following conditions: (a) consumers don't have the information necessary to make an informed choice between professionals, and (b) it is pretty fucking important that the job be done right. Doesn't make any sense to license those who program video games. DOES make sense to license those who design skyscrapers. Now, there are ways to alleviate the consumer's lack of knowledge. In my former racket (professional nursing), there is a lot of talk about benchmarking: comparing patient outcomes at different hospitals and publicizing the results. Market forces could then react to a nice, measurable reputation. But what about new, untested, solo practitioners? What about the architect whose buildings are all going to fall down, ten years from now? Even with well-publicized reputations, the consumer doesn't have the necessary information to keep from getting hurt. In those circumstances, it's useful to have standards, and a trusted public agency that certifies a person meets the standards. - -- ______________________________________________________________________ Don Doumakes Finger doumakes(a)netcom.com for PGP public key Foxpro databases built to your specifications. Email me for details. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLyWC1xtumcu2AjihAQGnRAP/UYqpg7gUpAyt7CMHgAUSApGHi9AFOJON UPns4os25F2B7op0uCdOQibbTJTUO5cjcDnpZ1VoYD00dFVN64IhoL/vYasoI1LV xm/grDW2bd4NKfOIYvbdYYwp8/BxtvCp9p8fGNksmHyWBPV017qieEo2rTHxuOWM lLwwSQYPp4o= =TW+P -----END PGP SIGNATURE-----

3 3

LAw in Cyberspace
by Ben 17 Dec '03

17 Dec '03

Well, Yale Law School is offering a class this semester on Law in Cyberspace. I'm going to audit it, and when I get a syllabus(tomorrow), I'll post a copy if folks are intersted. Just thought it would be of general interest. Ben ---- "By the end of 1648 all was over. Cromwell was Dictator. The Royalists were crushed; Parliament was a tool; the Constitution was a figment; the Scots rebuffed, the Welsh back in their mountains; the Fleet was reorganised, London overawed. King Charles, at Carisbrooke Castle, where the donkey treads the water wheel, was left to pay the bill. It was mortal." --Winston Churchill --_History_of_English_Speaking_Peoples Vol. II

1 0