August 2004 - cypherpunks-legacy

Re: Forensics on PDAs, notes from the field
by Major Variola (ret) 13 Aug '04

13 Aug '04

>On Fri, 13 Aug 2004, Thomas Shaddack wrote: >> In the world of industrial espionage and divorce lawyers, the FedZ aren't >> the only threat model. At 03:06 PM 8/13/04 -0400, Sunder wrote: >Right, in which case GPG (or any other decent crypto system) is just fine, >or you wouldn't be looking for stego'ing it inside of binaries in the >first place. I don't think Sunder grasps how much fun divorce lawyers can be. So, Mr. Smith, what *do* you hide with your crypto tools? And why won't you let the court examine the plaintext in camera, if your content is so benign? (Or are your ex-wife's accusations true?) Also, public schools prohibit the use of encryption. No kidding. And finding a crypto tool on a .mil slave's personal machine may be indicting evidence, given their lack of civilian legal processes, when accused by their own. Since mere possession of lockpick tools is criminal, do you really think you can possess crypto tools freely?

1 0

Re: Forensics on PDAs, notes from the field
by Major Variola (ret) 13 Aug '04

13 Aug '04

At 02:11 PM 8/13/04 -0400, Sunder wrote: >If you're suspected of something really big, or you're middle eastern, >then you need to worry about PDA forensics. Otherwise, you're just >another geek with a case of megalomania thinking you're important enough >for the FedZ to give a shit about you. Perhaps you're a geek working for people who think they're important enough? In any case, its not just the FedZ, the locals send the tricky shit to the FedZ if they don't have the LabZ. Same as with arson, poisonings, etc. So we all fall under the same logic-analyzer-panopticon.

1 0

Re: Forensics on PDAs, notes from the field
by Major Variola (ret) 13 Aug '04

13 Aug '04

At 01:46 PM 8/13/04 -0400, John Kelsey wrote: >>From: "Major Variola (ret)" <mv(a)cdc.gov> >>Obvious lesson: Steganography tool authors, your programs >>should use the worm/HIV trick of changing their signatures >>with every invocation. Much harder for the forensic >>fedz to recognize your tools. (As suspicious, of course). > >I would have thought the obvious lesson was to keep all your important work on an >encrypted disk partition, with a good password and a high iteration count. This is true not >just for criminals and terrorists, but for anyone who doesn't want the information on their >hard drive read by anyone who happens to steal their computer. If you include "PDA & Cellphone" as computer; or include "flash eeprom" as a "hard drive", then we agree. Most Persons of Interest will have secrets on their mobile gizmos (which use flash memory) as well as their PC's spinning disks. Sync'ing the PDA + PC means the security boundary includes them both. The important lesson is that all your gizmos will be seized and analyzed. And that the world needs good Linux-based-PDA & flash-mem-compatible security tools. And don't forget the epoxy...

1 0

Joux found a collision for SHA-0 !
by R. A. Hettinga 13 Aug '04

13 Aug '04

--- begin forwarded text

1 0

Re: Forensics on PDAs, notes from the field
by Tyler Durden 13 Aug '04

13 Aug '04

Sunder wrote... >And PGP won't stand out because.... ? Just wondering. Is it possible to disguise a PGP'd message as a more weakly encrypted message that then decrypts to something other than the true message? OK...perhaps we stego an encrypted message, then encrypt that photo using something weaker. Not like they haven't already thought of that, though. And it seems to me to be a difficult task getting ahold of enough photos that would be believably worth encrypting. -TD >From: Sunder <sunder(a)sunder.net> >To: Morlock Elloi <morlockelloi(a)yahoo.com> >CC: "cypherpunks(a)al-qaeda.net" <cypherpunks(a)al-qaeda.net> >Subject: Re: Forensics on PDAs, notes from the field >Date: Fri, 13 Aug 2004 14:11:36 -0400 (edt) > >On Fri, 13 Aug 2004, Morlock Elloi wrote: > > > The purpose would be that they do not figure out that you are using some > > security program, so they don't suspect that noise in the file or look >for > > stego, right? > > > > The last time I checked the total number of PDA programs ever offered to >public > > in some way was around 10,000 (5,000 ? 100,000 ? Same thing.) That can >be > > trivially checked for. Any custom-compiled executable will stand out as >a sore > > thumb. > >How? Not if you get something like a Sharp Zaurus and compile your own >environment. "Hey, I want to get as much performance out of this shitty >little ARM chip as I can." > > > You will suffer considerably less bodily damage inducing you to spit the > > passphrase than to produce the source and the complier. > >What makes you think they'll have enough of a clue as to how to read the >files off your PDA without booting it in the first place? 99% of these >dorks use very expensive automated hardware tools that do nothing more >than "dd" your data to their device, then run a scanner on it which looks >for well known jpg's of kiddie porn. > >If you're suspected of something really big, or you're middle eastern, >then you need to worry about PDA forensics. Otherwise, you're just >another geek with a case of megalomania thinking you're important enough >for the FedZ to give a shit about you. > > > Just use the fucking PGP. It's good for your genitals. > >And PGP won't stand out because.... ? > > >----------------------Kaos-Keraunos-Kybernetos--------------------------- > + ^ + :"Our enemies are innovative and resourceful, and so are we. /|\ > \|/ :They never stop thinking about new ways to harm our country /\|/\ ><--*-->:and our people, and neither do we." -G. W. Bush, 2004.08.05 \/|\/ > /|\ : \|/ > + v + : War is Peace, freedom is slavery, Bush is President. >------------------------------------------------------------------------- > _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 1

Forensics on PDAs, notes from the field
by Major Variola (ret) 13 Aug '04

13 Aug '04

Saint John of Cryptome has a particularly tasty link to http://csrc.nist.gov/publications/drafts.html#sp800-72 which describes the state of the art in PDA forensics. There is also a link to a CDROM of secure hashes of various "benign" and less benign programs that the NIST knows about. Including a list of "hacker" programs. Including stego. Pigs use this to discount commonly-distributed software when analyzing a disk (or, presumably, your PDA's flash). See http://www.nsrl.nist.gov/ also http://www.nsrl.nist.gov/Untraceable_Downloads.htm Obvious lesson: Steganography tool authors, your programs should use the worm/HIV trick of changing their signatures with every invocation. Much harder for the forensic fedz to recognize your tools. (As suspicious, of course). The NIST CDROM also doesn't seem to include source code amongst its sigs, so if you compile yourself, you may avoid their easy glance. Notes from the Field: My paper & image handling kiretsu job has a fellow working on secure Linux disk-drive delete --even if you pull the plug, on power up it finishes the job. Nice. Thank you, HIPAA, banks, etc.

4 7

Re: Forensics on PDAs, notes from the field
by John Kelsey 13 Aug '04

13 Aug '04

>From: "Major Variola (ret)" <mv(a)cdc.gov> >Sent: Aug 11, 2004 9:21 PM >To: "cypherpunks(a)al-qaeda.net" <cypherpunks(a)al-qaeda.net> >Subject: Forensics on PDAs, notes from the field ... >Obvious lesson: Steganography tool authors, your programs >should use the worm/HIV trick of changing their signatures >with every invocation. Much harder for the forensic >fedz to recognize your tools. (As suspicious, of course). I would have thought the obvious lesson was to keep all your important work on an encrypted disk partition, with a good password and a high iteration count. This is true not just for criminals and terrorists, but for anyone who doesn't want the information on their hard drive read by anyone who happens to steal their computer. --John

1 0

Re: Forensics on PDAs, notes from the field
by Major Variola (ret) 12 Aug '04

12 Aug '04

Quoth Thomas Shaddack <shaddack(a)ns.arachne.cz> > Obvious lesson: Steganography tool authors, your programs > should use the worm/HIV trick of changing their signatures > with every invocation. Much harder for the forensic > fedz to recognize your tools. (As suspicious, of course). It should be enough to do that at the installation time. The adversary in this model gets to analyze the file only once, and we want to make sure that nobody tampered with the file as a protection against other, more "active" threat models. What we want is to have a file and its hash, so we can make sure the file content is unchanged, but the hash has to be as globally-unique as possible. > The NIST CDROM also doesn't seem to include source code amongst its > sigs, so if you compile yourself, you may avoid their easy glance. A cool thing for this purpose could be a patch for gcc to produce unique code every time, perhaps using some of the polymorphic methods used by viruses. Just adding a chunk of data to make the hash unique will work against the current generation of the described tools. But we should plan to the future, what moves the adversary can do to counter this step. -------- Dear TS: you have very good ideas.

1 0

ONLamp.com: Anonymous, Open Source P2P with MUTE
by R. A. Hettinga 12 Aug '04

12 Aug '04

<http://www.onlamp.com/lpt/a/5015> Published on ONLamp.com (http://www.onlamp.com/) http://www.onlamp.com/pub/a/onlamp/2004/08/12/mute.html See this if you're having trouble printing code examples Anonymous, Open Source P2P with MUTE by Howard Wen 08/12/2004 The ongoing battle between users of file-sharing programs and media copyright-enforcement organizations (most notably the RIAA) has seemingly become a daily ping-pong match of lawsuits, threats of lawsuits, countersuits, office raids of commercial P2P services, and soda pop promotional gimmicks encouraging people to download music from legal music downloading services. Regardless of all the threats, intimidation, and spoofed music files clogging networks, P2P services in which users engage in "copyright infringement" (or "file sharing," if you prefer) continue to thrive. Activity on them still far surpasses the traffic of the legal music download sites, such as iTunes Music Store and the now legit Napster. One weakness of the P2P networks, including the infamous KaZaA, is the fact that it's so easy to identify a user's IP address. The Recording Industry Association of America (RIAA) has managed to use such extracted information to subpoena ISPs for the identities of potential defendants. Jason Rohrer has devised what could be the next technological headache for organizations like the RIAA: a P2P system that can mask the identity (or, at least, the IP address) of each user connected to it. Figuratively, he's done it by letting out the ants to ruin the RIAA's picnic. Rohrer, a 26-year-old programmer from Potsdam, New York, found inspiration in the way ants stream toward a food source. From observing the creatures' behavior, he mapped out a networking method that functions similarly - essentially, a shared file is the food source, and clients on the network are the ants seeking the food. He then wrote his own P2P program putting this theory to practice and christened it MUTE. Developed entirely in C++ and released as open source, the program runs on Linux, Win32, and Mac OS X. Figure 1. The MUTE file-sharing program running on Linux. Rohrer spoke with me for the O'Reilly Network, explaining how the ways of the ant could hold the key to anonymity for P2P users. Howard Wen: Give us a basic technical summary: What's the big difference between how the MUTE network works versus the traditional P2P method, such as KaZaA? Jason Rohrer:Traditional P2P networks can best be described as "direct download" systems. Nodes are linked together in a "mesh network," with each node connecting to a small number of neighbors. Certain pieces of information are broadcast and routed through the mesh, such as search requests and results. Downloads are not passed through the mesh - the downloader establishes a new, direct connection to the file source to start the transfer. Of course, a direct transmission means that the downloader needs to know the IP address of the file source. If you use TCP sockets - or UDP packets - properly, a direct transmission also means that the file source can find out the downloader's IP address. The RIAA has demonstrated that, with a subpoena or lawsuit, an IP address can easily be translated into a human name and postal address. In other words, any system that relies on direct downloads is not anonymous, due to intrinsic properties of Internet routing. A MUTE network is very similar in form to a traditional P2P network: MUTE nodes connect to each other in a mesh network, with each node maintaining a small number of direct links to neighbor nodes. In addition to routing search requests and results through the mesh, MUTE routes everything else, including file transfers. Thus, a downloader does not need to know the IP address of a file source, since the downloader never needs to make a direct connection, and a download is routed through the chain of nodes that separate the downloader from the file source. Routed downloads are what separates MUTE from other search-and-download P2P networks. Of course, routed downloads alone do not provide anonymity. Even more crucial is the way that MUTE routes messages anonymously. Each MUTE node generates a random virtual address for itself at startup. Messages are tagged as being "from" one virtual address and "to" another virtual address, though only the sending node knows that it owns the "from" address, and only the receiving node knows that it owns the "to" address. None of the other nodes in the network know which node owns either of these addresses. As messages travel through the network, they leave behind local "scent" - or routing - information for their "from" address at each node that they pass through. For example, if a message from Alice passes through a node, the node records that it has received messages from Alice from one of its neighbors. In the future, if that node receives a message to Alice, it can use this scent to direct the message onward through that neighbor. Each node essentially maintains directional hints about which direction Alice is in, though no one knows for sure which node is actually Alice. HW: What are the inherent difficulties in designing a P2P, or shared network, system, overall? JR: I have developed several P2P applications in the past, including applications that rely heavily on cryptography, so those aspects weren't really a challenge this time around. However, MUTE was the first platform-independent C++ application for which I wanted to develop a true, natively compiled GUI, and this was a major challenge. I evaluated several toolkits, and several factors weighed into my decision. First, I had three target platforms in mind: GNU/Linux, Mac OS X, and Win32. So, I needed a toolkit that supported all of them. Second, I couldn't afford to pay for a toolkit, so I needed a toolkit with an unrestrictive license. Third, I wanted a toolkit that would make use of C++, since object-oriented abstractions seem particularly well-suited for GUIs. These factors essentially ruled out every toolkit except for wxWindows [Editor's note: now known as wxWidgets.] The real challenge came in learning a new toolkit. wxWindows is powerful and feature-rich, but the API is a little quirky. In addition, there were wxWindows build hurdles for the various platforms. For example, my customary Win32 compiler - I sheepishly admit that it was an outdated version of CodeWarrior - couldn't compile the wxWindows library, so I had to switch to a completely different, and unfamiliar, build environment: MinGW. I also had to grudgingly accept that my chosen GUI library was between 2 and 4 times larger than the rest of my application. I detest code bloat, but I really had no choice. The upshot is that MUTE can be downloaded and run natively on both Mac OS X and Win32, even though my development platform was GNU/LinuxPPC. The code that generates and runs the GUI is identical on all three platforms. HW: Have you theorized other aspects of ant behavior that could be applied to effective networking, besides masking a user's identity? JR: In nature, ants tend to find the shortest path between their nest and a food source. Many different paths are traversed at first, but since ants can complete roundtrips more frequently on the shorter paths, the shorter paths receive more traffic and thus more pheromone scent, which in turn leads to more traffic - ants move toward the strongest scents. Eventually, the scent on the shortest path is so strong that all of the ants travel along this path. MUTE's ant-routing also discovers "short" paths between a sender and receiver. However, the fast roundtrip time is what makes a path attractive to MUTE messages. In low-traffic situations, the fastest path will often be the shortest one with the fewest hops. As traffic increases, however, a short path may become slower if it is overloaded, and a longer path with less traffic may be faster. Thus, using only local routing clues, MUTE can automatically balance load throughout the network and avoid congested routes. Of course, you only need this kind of load-balancing if you are routing, and routing only makes sense if you are trying to protect anonymity. While load-balancing is a nice feature and will help MUTE's scalability, it is by no means a standalone selling point for MUTE. In other settings, such as ad-hoc wireless networks, ant-based routing is very attractive and heavily researched. Because MUTE is built as an overlay network on top of the TCP socket abstraction, its ant-routing cannot be used out-of-the box to improve performance in an ad-hoc network. However, MUTE can be seen as a good research platform for exploring the properties of ant-routing, since it is one of the first widely deployed networks to use it. HW: What are the limitations of MUTE? Does it scale up well in performance compared to the other P2P methods? I've read theories suggesting that MUTE might not be able to handle the load if the number of users on it is too large. How many people would you hazard to guess MUTE can effectively serve, in its current version? JR: If you want uploader/downloader anonymity, you simply cannot use direct downloads. Indirect downloads always involve a substantial performance and scalability hit. Even if you ignore the effect on overall transfer speed, you still have at least one additional node involved in each download, which in turn increases the load induced by each download. For example, suppose you have a direct download network of 100 nodes that can support 50 simultaneous transfers - half the nodes are uploaders and half are downloaders. If you now force each transfer to involve an additional intermediary node, while keeping similar bandwidth constraints, you can only support 33 simultaneous transfers: one-third uploading, one third-downloading, and the other third relaying. I will claim that using a single relay or proxy for each transfer doesn't provide enough anonymity. How can you trust your chosen proxy? What if the adversary happens to be operating the proxy that you choose? The same holds true for any system that uses fixed number of proxies for each transfer. If all transfers use two proxies, and you happen to pick two "adversary" nodes to proxy your transfer, your anonymity is compromised. MUTE uses a variable number of intermediary nodes for each transfer, with the network topology dictating how long each transfer chain is. No matter how many nodes in a transfer chain are controlled by the adversary, the adversary can never be sure that it controls all of the nodes in the chain. Thus, the adversary can never obtain the identity of the uploader or downloader with any degree of certainty. Since there is no fixed limit to how many nodes a MUTE transfer can pass through, there is also no limit on how much load is induced by a transfer or how slow that transfer will be, and this is where the scalability concerns arise. Each additional user in the network is likely to initiate additional downloads, which will each increase the load on the network. Of course, if you want decent anonymity, you must make this kind of tradeoff. To answer questions about how well MUTE will scale, we need to answer other questions first: How slow must a transfer become before it is considered useless? How much bandwidth will the average user dedicate to the MUTE network? How many downloads will each user be requesting? As an extreme example, consider the case in which no one is downloading anything: MUTE can scale limitlessly. At the other extreme, if everyone expects fast transfers and wants to be downloading 100 files simultaneously, MUTE won't scale beyond a handful of users. Also, I think it depends on how much users value anonymity. A slow anonymous download may be more valuable than a fast download that could land you in court. The same tradeoff operates for quantity: one anonymous download a day may be more valuable than 100 non-anonymous downloads. As an example, we can assume that a transfer is worthwhile as long as it is coming in at over 5KB/second. If we assume that everyone has a cable modem with a tight upstream bottleneck, then each node can handle relaying or uploading about three files simultaneously. Next, we can assume that each download passes through four intermediary nodes on average. If we have a network of 1,000 nodes, then we can support at most 600 simultaneously downloads at decent rates - each download taxes the upstream bandwidth of five nodes, and each node can handle being taxed by three simultaneous transfers. Of course, these calculations change as the assumptions change, but we have just laid out assumptions that would suggest that MUTE could support 60% of its users downloading one file each at worthwhile rates. As the percentage of downloaders increase in this network, the download rates would decrease throughout the network. With the above assumptions, each additional node contributes three transfers worth of bandwidth, but would consume five such units of bandwidth if it were to download. If we reduce the worthwhile transfer rate to 3KB/second, then we achieve a balance: Each additional node can request a download, since it contributes the same amount of bandwidth that its download consumes, so MUTE could support 100% of its users downloading one file each. If users curb how many simultaneous downloads they request and are content with the resulting transfer rates, then MUTE can scale limitlessly. However, if everyone else is "playing nice," you can increase your personal gain by initiating additional downloads for yourself and abusing the network. Keeping this kind of greed in check is difficult, especially in an anonymous network. HW: Could the MUTE technology be used for other things, besides file-sharing? JR: Before I even thought about applying MUTE to file-sharing, I wrote modules that performed anonymous chat and web-serving over MUTE. Given the current legal landscape, the file-sharing problem was much more pressing, so I have completely switched gears to focus on that. However, MUTE can certainly be used for other anonymous communication applications. HW: What features do you plan to add to future versions of MUTE? JR: I have always intended to keep MUTE simple: It provides anonymous file-sharing, and to my knowledge it is the first application to do so. I want to avoid having MUTE be a catchall for the latest, snazziest file-sharing and user-interface features. I have been improving the robustness of download retries to ensure that downloads can weather traffic spikes and routing problems without failing unnecessarily - several user-submitted patches have been very helpful here. I am also adding a few simple user-interface elements that make MUTE nicer to use, such as a user-submitted patch for better upload statistics. Once MUTE is a solid, usable, and comfortable file-sharing application, my work will be done. Those who want all of the fancy, trendy features can start their own project, add the features, and release their own version of MUTE. My contribution is anonymous file-sharing. HW: Do you need volunteers? What skills and contributions do you need the most? JR: I have been looking for people who have an idea for a feature that can be added to MUTE in a modular fashion, with a clean API separating it from the rest of the MUTE code. HW: What advice do you have for those who might want to modify the MUTE source? JR: MUTE is a layered architecture. The bottom layer is a secure socket implementation that is used to encrypt the contents of neighbor connections. Above that is the MUTE routing layer, which features a very clean API for controlling a MUTE node and sending or receiving messages through it. The file-sharing layer is built on top of the routing API, and it has a clean API of its own, which supports various file-sharing operations, like searching and downloading. The user interfaces are built on top of the file-sharing API, and two are included in the source: a text-based interface and a wxWindows GUI. If you want to build your own communication service on top of MUTE routing, I would suggest taking a look at the routing API. If you want to build a new client for file sharing - for example, a platform-specific GUI, then the file-sharing API will be useful. Understanding these layer APIs will also help you to modify the existing MUTE client. HW: As a programmer, what are some of the things you've been learning as you've been working on MUTE? JR: I have been programming for years, but my coding techniques improve every day. I'm always looking for more elegant ways to do things, and looking back at last year's code can be frustrating. I find the same to be true for any creative process, including writing, visual arts, and music: Since you constantly improve, your past work feels particularly shoddy in retrospect. My coding has improved in many subtle ways that I cannot necessarily put my finger on. In terms of more dramatic changes, the use of a layered architecture has made the MUTE project very easy to manage and understand. I have never used a layered architecture before, but I plan to use it in the future. HW: Have you considered the legal ramifications of what you're doing and prepared for any possible legal action? As everybody knows, the RIAA and its international counterparts have been going after both users and developers of P2P software quite aggressively. JR: So far, these organizations have confined their attacks to corporations that are peddling P2P and making money off of it. There is no precedent for a suit against an individual P2P developer who is releasing non-commercial, open-source software. Selling a product that helps people break the law is very different from giving it away. Furthermore, there is no explicit law against software like MUTE. That said, I could always be the precedent, and I am ready for anything. I believe that coding is part of my right to free speech, and I also believe that I have the right to encourage people to break an unjust law as a form of social protest. Many people look at the MUTE web site, which refers directly to how MUTE circumvents the RIAA's spy tactics, and say, "Whoa, friend, I would be careful if I were you." Sure, many other P2P developers and companies blatantly lie about what their software is for, but I refuse to lie. You can write a book that encourages people to break the law - for example, The Anarchist Cookbook. Why can't I write a web site that does the same thing? To be honest, I think it is highly unlikely I will be sued, but only time will tell. HW: It's inevitable that a third-generation P2P service is probably on the horizon. Will you be so bold to say that yours, MUTE, is it? JR: Whatever the third-generation P2P system will be, it will certainly be anonymous. All past P2P innovations have been spurred by the legal tactics of the day. I don't see why the next leap will be any different. MUTE is probably more of a vanguard than the be-all, end-all third-generation P2P system, much like Gnutella was the vanguard for the second generation. Other P2P developers may be inspired by MUTE and start thinking about how to make P2P anonymous. Unfortunately, if history repeats itself, the most popular third-generation network may be owned by a corporation that was ultimately inspired by my work on MUTE. It would be nice to see an open-source and open-protocol network win this round, if only to ensure that at least one open-source application was on the majority of people's desktops. Howard Wen is a freelance writer who has contributed frequently to O'Reilly Network and written for Salon.com, Playboy.com, and Wired, among others. -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

RE: 2+2=5 and mention of cryptome
by Tyler Durden 12 Aug '04

12 Aug '04

Nah. They wanted to cock-block Kerry and his high visibility as a result of the DNC. As for inconveniencing this New Yorker, it was barely worse than it usually is going down to Wall Street. The RNC will be another story altogether, however. -TD >From: Sunder <sunder(a)sunder.net> >To: cypherpunks(a)al-qaeda.net >Subject: 2+2=5 and mention of cryptome >Date: Thu, 12 Aug 2004 16:38:22 -0400 (edt) > > >Original URL: >http://www.theregister.co.uk/2004/08/11/al_q_geek_us_overthrow_plot/ > >Al-Qaeda computer geek nearly overthrew US >By Thomas C Greene (thomas.greene at theregister.co.uk) >Published Wednesday 11th August 2004 16:45 GMT > >Update A White House with a clear determination to draw paranoid >conclusions from ambiguous data has finally gone over the top. It has now >implied that the al-Qaeda computer geek arrested last month in Pakistan >was involved in a plot to destabilize the USA around election time. > >Two and two is five > >As we reported here >(http://www.theregister.co.uk/2004/08/03/us_terror_alert_political_football) >and here >(http://www.theregister.co.uk/2004/08/02/al_qaeda_cyber_terror_panic) >so-called al-Qaeda "computer expert" Muhammad Naeem Noor Khan, a >Pakistani, was arrested on 13 July in possession of detailed but rather >old surveillance documents related to major financial institutions in New >York, Newark, and Washington. > >Since that time, other intelligence has led the US security apparatus to >imagine that a plot to attack the USA might be in the works. (No doubt >there are scores of plots in the works, but we digress.) Therefore, last >week, the ever-paranoid Bush Administration decided that Khan's building >surveillance documents, and the hints of imminent danger, had to be >connected. Indeed, if al Qaeda is to strike at all, it is most likely to >strike the targets mentioned in Khan's documents, as opposed to thousands >of others, the Bushies reasoned. > >New York, Newark and Washington were immediately put on high alert, at >great expense, and to the inconvenience of millions of residents. > ><SNIP> > >----------------------Kaos-Keraunos-Kybernetos--------------------------- > + ^ + :"Our enemies are innovative and resourceful, and so are we. /|\ > \|/ :They never stop thinking about new ways to harm our country /\|/\ ><--*-->:and our people, and neither do we." -G. W. Bush, 2004.08.05 \/|\/ > /|\ : \|/ > + v + : War is Peace, freedom is slavery, Bush is President. >------------------------------------------------------------------------- > _________________________________________________________________ Get ready for school! Find articles, homework help and more in the Back to School Guide! http://special.msn.com/network/04backtoschool.armx

1 0