From crypto-gram-return-30-waynec=spinnaker.com@chaparraltree.com Fri Sep 15 01:17:54 2000 Return-Path: Received: from dd-b.net (gw.dd-b.net [63.224.10.74]) by schooner.spinnaker.com (8.9.3/8.9.3) with SMTP id BAA05786 for ; Fri, 15 Sep 2000 01:17:40 -0700 (PDT) Received: (qmail 14285 invoked by uid 519); 15 Sep 2000 07:26:55 -0000 Mailing-List: contact crypto-gram-help@chaparraltree.com; run by ezmlm Precedence: bulk Delivered-To: mailing list crypto-gram@chaparraltree.com Delivered-To: moderator for crypto-gram@chaparraltree.com Received: (qmail 14239 invoked from network); 15 Sep 2000 07:24:23 -0000 Message-Id: <4.2.2.20000915000835.03828d50@chaparraltree.com> X-Sender: schneier@counterpane.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 15 Sep 2000 00:39:26 -0500 To: crypto-gram@chaparraltree.com From: Bruce Schneier Subject: CRYPTO-GRAM, September 15, 2000 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Status: O Content-Length: 37072 Lines: 930 CRYPTO-GRAM September 15, 2000 by Bruce Schneier Founder and CTO Counterpane Internet Security, Inc. schneier@counterpane.com A free monthly newsletter providing summaries, analyses, insights, and=20 commentaries on computer security and cryptography. Back issues are available at . To subscribe or= =20 unsubscribe, see below. Copyright (c) 2000 by Counterpane Internet Security, Inc. ** *** ***** ******* *********** ************* In this issue: Full Disclosure and the Window of Exposure _Secrets and Lies_ News Crypto-Gram Reprints News Counterpane Internet Security News Carnivore Disinformation FBI Requires Constitutional Changes The Doghouse: FaceMail PGP Vulnerability Comments from Readers ** *** ***** ******* *********** ************* Full Disclosure and the Window of Exposure To read this essay with the nifty graphs, see: Every season yields a bumper crop of computer security stories: break-ins,= =20 new vulnerabilities, new products. But this season has also given us a=20 crop of stories about computer security philosophy. There has been a=20 resurgence in opposition to the full disclosure movement: the theory that=20 states that publishing vulnerabilities is the best way to fix them. In=20 response, defenders of the movement have published their rebuttals. And=20 even more experts have weighed in with opinions on the DeCSS case, where a= =20 New York judge ruled that distributing an attack tool is illegal. What's interesting is that everybody wants the same thing; they're just=20 disagreeing about the best way to get there. When a security vulnerability exists in a product, it creates what I call a= =20 window of exposure. This window exists until the vulnerability is patched,= =20 and that patch is installed. The shape of this window depends on how many= =20 people can exploit this vulnerability, and how fast it is patched. What=20 everyone wants is to make this window as small as possible. A window of exposure has five distinct phases. Phase 1 is before the=20 vulnerability is discovered. The vulnerability exists, but no one can=20 exploit it. Phase 2 is after the vulnerability is discovered, but before=20 it is announced. At that point only a few people know about the=20 vulnerability, but no one knows to defend against it. Depending on who=20 knows what, this could either be an enormous risk or no risk at=20 all. During this phase, news about the vulnerability spreads -- either=20 slowly, quickly, or not at all -- depending on who discovered the=20 vulnerability. Of course, multiple people can make the same discovery at=20 different times, so this can get very complicated. Phase 3 is after the vulnerability is announced. Maybe the announcement is= =20 made by the person who discovered the vulnerability in Phase 2, or maybe it= =20 is made by someone else who independently discovered the vulnerability=20 later. At that point more people learn about the vulnerability, and the=20 risk increases. In Phase 4, an automatic attack tool to exploit the=20 vulnerability is published. Now the number of people who can exploit the=20 vulnerability grows exponentially. Finally, the vendor issues a patch that= =20 closes the vulnerability, starting Phase 5. As people install the patch=20 and re-secure their systems, the risk of exploit shrinks. Some people=20 never install the patch, so there is always some risk. But it decays over= =20 time as systems are naturally upgraded. In some instances the phases are long, and sometimes they're=20 short. Sometimes Phase 5 happens so fast that Phases 3 and 4 never=20 occur. Sometimes Phase 5 never occurs, either because the vendor doesn't=20 care or no fix is possible. But this is basically the way things work. The goal of any responsible security professional is to reduce the window=20 of exposure -- the area under the curve -- as much as possible. There are= =20 two basic approaches to this. The first is to reduce the window in the space dimension by limiting the=20 amount of vulnerability information available to the public. The idea is=20 that the less attackers know about attack methodologies, and the harder it= =20 is for them to get their hands on attack tools, the safer networks=20 become. The extreme position in this camp holds that attack tools should=20 be made illegal. This might work in theory, but unfortunately it is impossible to enforce in= =20 practice. There is a continuous stream of research in security=20 vulnerabilities, and most of this research results in public=20 announcements. Hackers write new attack exploits all the time, and the=20 exploits quickly end up in the hands of malicious attackers. Any one=20 country could make some of these actions illegal, but it would make little= =20 difference on the international Internet. There have been some isolated=20 incidences of a researcher deliberately not publishing a vulnerability he=20 discovered, but public dissemination of vulnerability information is the=20 norm...because it is the best way to improve security. The second approach is to reduce the window of exposure in time. Since a=20 window remains open until the vendor patches the vulnerability and the=20 network administrator installs the patches, the faster the vendor can issue= =20 the patch the faster the window starts closing. To spur the vendors to=20 patch faster, full-disclosure proponents publish vulnerabilities far and=20 wide. Ideally, the vendor will distribute the patch before any automatic=20 attack tools are written. But writing such tools can only hasten the= patches. This also works a lot better in theory than in practice. There are many=20 instances of security-conscious vendors publishing patches in a timely=20 fashion. But there are just as many examples of security vendors ignoring= =20 problems, and of network administrators not bothering to install existing=20 patches. A series of credit card thefts in early 2000 was facilitated by a= =20 vulnerability in Microsoft IIS that was discovered, and a patch released=20 for, a year and a half earlier. The problem is that for the most part, the size and shape of the window of= =20 exposure is not under the control of any central authority. Not publishing= =20 a vulnerability is no guarantee that someone else won't publish=20 it. Publishing a vulnerability is no guarantee that someone else won't=20 write an exploit tool, and no guarantee that the vendor will fix=20 it. Releasing a patch is no guarantee that a network administrator will=20 actually install it. Trying to impose rules on such a chaotic system just= =20 doesn't work. And to make matters worse, it's never one single vulnerability. There are= =20 dozens and hundreds of vulnerabilities, all with overlapping windows. One= =20 vulnerability might be shrinking while another ten are growing. We're like= =20 the little Dutch boy, plugging leaks in the dike with our fingers while=20 others spring up nearby. It doesn't matter if we believe that full=20 disclosure is the best way to reduce the window's size or if quietly=20 alerting the vendor does better...we're going to lose the war fighting it=20 either way. Vulnerabilities are inevitable. As our networks get more complex and more= =20 pervasive, the vulnerabilities will become more frequent, not less. We're= =20 already seeing this; every year brings more security holes than the=20 previous one. The only way to close the window of exposure is to make it=20 not matter. And the only way to do that is to build security systems that= =20 are resilient to vulnerabilities. In _Secrets and Lies_, I talk about security processes that make systems=20 resilient to vulnerabilities. The most relevant one to this debate is=20 detection and response. Most computer-security products are sold as=20 prophylactics: firewalls prevent network intrusions, PKI prevents=20 impersonation, encryption prevents eavesdropping, etc. The problem with=20 this model is that the product can either succeed or fail: either the=20 window of exposure is closed or it is open. Good security includes not=20 only protection, but also detection and response. An Internet alarm system= =20 that detects attacks in progress, regardless of the vulnerability that was= =20 exploited, has the ability to close the window of exposure completely. The key to Internet detection and response is vigilance. Attacks can=20 happen at all times of the day and night, and any day of the year. New=20 attack tools appear all the time; new vulnerabilities become public all the= =20 time. I built Counterpane Internet Security, Inc. as a managed security=20 monitoring company because I saw this as the only way to bring security to= =20 computer networks. Without outsourced detection and monitoring, we're at=20 the mercy of all the hackers and product vendors and security professionals. Those advocating secrecy are right that full disclosure causes damage, in=20 some cases more damage than good. They are also right that those who build= =20 attack tools should be held liable for their actions; the defense of "I=20 just built the bomb; I didn't place it or set the fuse" rings hollow. But= =20 they are wrong to think they can enforce secrecy. Information naturally=20 disseminates, and strategies that go against that are doomed. Those=20 advocating full disclosure are right that rapid dissemination of the=20 information benefits everyone, even though some people make ill use of that= =20 information. We would be in a much worse position today if vulnerability=20 information were only in the hands of a privileged few. Neither full disclosure nor secrecy "solve" computer security; the debate=20 has no solution because there is no one solution. Both sides are missing=20 the point. The real issue, how to close the window of exposure, is more=20 subtle. We have to stop thinking of software security as an end state,=20 that fixing the bugs will somehow make the software perfect. Security=20 vulnerabilities are inevitable and there will always be a window of=20 exposure; smart security solutions will work regardless. Marcus Ranum started this debate at BlackHat. A transcript of his talk=20 isn't available on-line, but these two essays are: Weld Pond's rebuttal: Stuart McClure and Joel Scambray's rebuttal: Another view: News article: My older writings on this topic: ** *** ***** ******* *********** ************* _Secrets and Lies_ News _Secrets and Lies_ is officially published. This means that you can walk=20 into a bookstore and buy it. Last month, when I announced the book, it was= =20 printed and in the Wiley warehouse but not in bookstores. Initial feedback has been great. There are already reviews on the=20 Amazon.com Web site. The Economist published a review of the book, as did= =20 Business Week, Industry Standard, New Scientist, and Salon. Other reviews= =20 are coming in the next few weeks. Here's the publishing information: Secrets and Lies: Digital Security in a Networked World Bruce Schneier John Wiley & Sons, 2000 ISBN: 0-471-25311-1 $29.99 Book Web site: See the Table of Contents: Read the Preface: Amazon.com has posted Chapter 3: Buy the book here: Reviews: All reviews: Bruce Schneier is planning a book tour for October. Planned locations=20 include San Francisco, San Jose, Seattle, Portland, New York, Boston, and=20 Washington, DC. Tour dates and locations can be found here: ** *** ***** ******* *********** ************* Crypto-Gram Reprints Open-source and security: Factoring a 512-bit number: ** *** ***** ******* *********** ************* News Another massive net attack coming? http://www.zdnet.com/zdnn/stories/news/0,4586,2614854,00.html Analytic Thinking and Presentation for Intelligence Producers, Analysis=20 Training Handbook. By the CIA's Office of Training and Education. How one bank survived a security audit: In an effort to identify potential= =20 security risks, a bank shares its experiences of having its systems=20 scrutinized. Software Risk Management Conference: Why Microsoft doesn't have to improve security. Cheaper technologies than PKI: There's a lot of snake-oil in this article, but some of the ideas are good. A good article on the difficulty of normal people actually using security=20 technology. Hacking insurance (a good article). An excellent analysis of the DeCSS decision by Emmanuel Goldstein. Worth=20 reading. Now that CSS is broken, the DVD manufacturers have another dumb idea:=20 watermarking. Internet bank robbery: The bank is claiming that no money was stolen, and the truth seems very=20 mundane. And the culprits have been apprehended. Two good articles on encryption algorithms, the first on DES and the second= =20 on AES. It's over six months since last February's massive distributed=20 denial-of-service attacks. One survey found over 100,000 computers still=20 vulnerable. What does it take to get through to some people? New trend: breaking into networks and extorting money out of the owners: New computer virus (similar to the Love Bug, but with a much nastier=20 payload) targets children: The safety of open source operating systems: TRUSTe violating its own security policy? Weren't they the ones who told=20 us that self-regulation would work? JAVA emulators of WWII crypto devices: Purple, Sigaba, Enigma, Russian=20 Espionage Cipher, and a public domain Bombe. Good descriptions, too. First malware for the Palm Pilot (a Trojan horse): And a response from anti-virus companies: Password crackers: This site lists all sorts of password crackers that run= =20 dictionary attacks against a variety of encryption products. My own=20 Password Safe is on the list; there's a password cracker for that,=20 too. The moral is not to choose a guessable password, and that more and=20 more passwords become guessable every year. Schneier and security: In a bizarre twist, @Stake (a company filled with hackers) refuses to hire= =20 someone because he's a reformed (but once convicted) hacker. I understand= =20 the reluctance to hire criminals, but it seems hypocritical to make a=20 hiring decision based on whether someone was caught hacking ten years ago=20 or whether he got away with it. A good essay on the risks of Carnivore: A Thai company has developed a security robot that can shoot=20 criminals. According to the company: "It is armed with a pistol that can=20 be programmed to shoot automatically or wait for a fire order delivered=20 with a password from anywhere through the Internet." Words fail me on this one. More web bugs. Someone can add a web bug to a Microsoft Word document and= =20 track who opens it. Nasty side effect of being online all the time. A demonstration bugged document: News articles: Microsoft's response to the web bugs is pretty weird. They make a big deal= =20 about cookies, not web bugs. It's sort of like they missed the point=20 completely. RSA Inc. executes a clever publicity move. Many events and parties are=20 planned to commemorate the expiration of the RSA algorithm patent on 20=20 September 2000. So what does RSA Inc. do? They put the algorithm in the=20 public domain two weeks early and pre-empt the publicity. Meaningless, but= =20 pretty clever. DDOS tools get even easier to use: Another Microsoft bug (this one in NetBIOS). This one affects Windows 95,= =20 98, NT, and 2000. The really odd piece of this story is that Microsoft=20 doesn't plan on releasing a patch for this one.) Global tracking and MSN GUID. Nasty privacy violation. Internet Explorer persistence. Yet another Microsoft security problem: Amazon.com leaks customer e-mail addresses: The Secure Digital Music Initiative is having a hacking contest to see=20 which of their content protection schemes are better. I've already written= =20 about why hacking contests make no sense, and don't do anything to show=20 which scheme is better. I've also already written about why the whole=20 concept of content protection is flawed, and that it doesn't matter how=20 good the scheme is. Self-propagating security patch...in rabbits! The story of the stolen Bletchley Park Enigma machine gets wierder: The European Telecommunication Standards Institute (ETSI) has made a bunch= =20 of encryption algorithms public: A just-released GAO report gives the government bad marks when it comes to= =20 security. Collectively, the agencies averaged D-, with more than a quarter= =20 of them flunking, and only two out of twenty-four agencies getting better=20 than a C rating. ** *** ***** ******* *********** ************* Counterpane Internet Security News Bruce Schneier is speaking at the eCFO Conference in Atlanta, on 19= September. Bruce Schneier is speaking at the E-Business Security Summit in Chicago, on= =20 4 October. ** *** ***** ******* *********** ************* Carnivore Disinformation This bit, from Newsweek's Periscope, sounds very much like government=20 propaganda: Tracking bin Laden's E-Mail American counter-terrorism experts are aghast that the FBI has gone public= =20 with Carnivore, its new Internet-wiretap system. The reason for their=20 dismay: Osama bin Laden uses e-mail to communicate with his terrorist=20 network. The intelligence community's ability to track his messages has=20 been, according to one intelligence source, "the biggest single factor in=20 shutting down several planned operations," including some in the United=20 States. "Bin Laden thought his communications were secure," says the=20 source. "They weren't. Now we've told him." FBI officials acknowledge that Carnivore has been used about 25 times,=20 primarily in terrorism investigations. But they decline to comment on its= =20 use against bin Laden. "Everyone knows we can wiretap phones," says a=20 bureau spokesman. "There's no reason why an ability to intercept e-mails=20 must necessarily be covert." ** *** ***** ******* *********** ************* FBI Requires Constitutional Changes It's hard to know what to think of this: "One of the FBI requirements for the Internet kiosks at the 2002 Olympics=20 is that the FBI be able to record all passwords, copy all sent email, and=20 divert sent email for administrative decisions on whether it should be=20 delivered." If it is true, it is the most intrusive power grab we've seen so=20 far. Would there even be warning notices on the kiosks? Would they demand= =20 eavesdropping rights on all direct computer hookups as well? The mind= boggles. ** *** ***** ******* *********** ************* The Doghouse: FaceMail FaceMail uses your "personal biometric facial template" to encrypt and=20 decrypt emails. They don't say what happens if someone else steals your=20 key or if you have surgery. Zero technical details can be found at: ** *** ***** ******* *********** ************* PGP Vulnerability A very serious PGP vulnerability was just discovered. Using this=20 vulnerability, an attacker can create a modified version of someone's=20 public key that will force a sender to encrypt messages to that person AND= =20 to the attacker. Let me explain. Starting with PGP version 5.5, the software supported something called an=20 Additional Decryption Key (ADK). Normally, when a PGP user creates a PGP=20 certificate, it contains a single public key (as well as identifying=20 information as to who the key belongs to). PGP version 5.5 and 6.x allow=20 the user to add additional ADKs to the certificate. When a sender encrypts= =20 a message to that user, PGP will automatically encrypt the message in both= =20 the user's public key and the ADK. The idea is that the ADK belongs to the= =20 secret police, or the user's employer, or some organization, and that=20 organization can intercept the encrypted message and read it. (On Slashdot I said that Network Associates did this when they joined the=20 Key Recovery Alliance, but PGP Inc. added the feature before then. They=20 needed it to get certain corporate contracts.) The flaw is that some version of PGP don't require the ADKs to be in the=20 signed portion of the PGP certificate. What this means is that an=20 organization can take a PGP certificate, append his ADK, and spread it out= =20 to the world. This tampered version of the certificate will remain=20 unnoticed by anyone who doesn't manually examine the bytes, and anyone=20 using that tampered version will automatically and invisibly encrypt all=20 messages to the organization as well as the certificate owner. Colleague Greg Guerin likened the lesson of this vulnerability to something= =20 he learned in kindergarten: "Don't put something in your mouth unless you=20 know where it's been." The reaction from Network Associates has been pretty good: they fixed the=20 problem. Unfortunately, the president of the PGP Security unit=20 demonstrated a high degree of cluelessness when he said: "This a fairly=20 esoteric attack. It's not likely that anybody without specialized=20 knowledge could use it." Certainly it is an esoteric attack but, as we all= =20 know, that person with specialized knowledge could easily encapsulate the=20 attack in a point-and-click program that any script kiddie could use. On the plus side, it doesn't seem like anyone took advantage of this=20 vulnerability. Network Associates inspected all 1.2 million PGP keys on=20 its keyserver, and found none of them were tampered with in this way. Way back in 1997 a bunch of us cryptographers predicted that adding key=20 escrow would make system design harder, and would result in even more=20 security problems. This is an example of that prediction coming true. Research paper on the vulnerability: CERT Advisory: Slashdot article: News reports: Nice summary article: Network Associates reaction: 1997 Risks of Key Escrow Paper: ** *** ***** ******* *********** ************* Comments from Readers From: Brian Taylor Subject: PGP Vulnerability and the DMCA I have copyrighted works protected with PGP. I did not consent to the TPM= =20 I use being circumvented. Bruce's description of this vulnerability is=20 clearly a circumvention technology that will be used to pirate my work and= =20 is thereby illegal under the DMCA. I'm going to file a lawsuit against Bruce and Slashdot and anyone who links= =20 to Slashdot and anyone who reads the article and anyone who points at or=20 otherwise refers to a person who reads the article. In fact, Bruce himself= =20 is circumvention technology, so I'm suing his parents, too, along with the= =20 major airlines, both of which have distributed Bruce. From: Aleph One Subject: Firewalls and tunnelling protocols Firewalls were never meant to stop covert channels. While it's all too true that current firewalls performs a rather lacking=20 job at verifying that a protocol they are forwarding meets its=20 specification, and you could certainly be creative and attempt to find ways= =20 to detect and stop covert channels, as long as the firewalls allows some=20 traffic through, any traffic, a covert channel will be possible. So the real problems are in your expectation of a firewalls capabilities,=20 something all too common, and in vendors exploiting overly generic and=20 complex protocols to bypass what they see as nothing more that an annoyance= =20 to the ease of use and deployment of their application. From: "Scott Tousley" Subject: SANS I think you let SANS wriggle off the hook in your article from two weeks=20 ago, and I think their fingerprints from the MSNBC article runs the same=20 direction. While I'm not convinced that Genuity, UUNet, AT&T, C&W, Sprint,= =20 PSINet and others are doing all that our business motivation demand, I also= =20 do not think that the answer is found in a loose confederation of SANS,=20 CERT CC, OMB/FEDCIRC, and WH/NSC/CIAO staff designing private-sector=20 requirements. SANS now and CERT CC in the past have contributed to some=20 good work for network security, but I do not think this means they should=20 take an operational role and drive the private sector on behalf of the=20 government. The SANS stumbling over the Microsoft problem is a reflection= =20 of this inappropriate role. From: "Gary Hinson" Subject: SANS I completely agree with your editorial about the SANS news flash thing. It= =20 has done their credibility no good at all, which is such a shame because=20 (until then) I had been very impressed with the SANS services and their=20 (usually) tempered tone. It seems quite out of character, in fact I=20 wondered if someone had hacked the SANS emailer and sent out a spoof! The= =20 'virus to catch a virus' was really over the top! From: "Mikolaj J. Habryn" Subject: Bluetooth If you visit www.bluetooth.com, you will find that the full specifications= =20 (1400 pages long and amusingly captioned 'Wireless Connections Made Easy')= =20 are available and include information on link encryption and key generation= =20 and exchange mechanisms. The specifications do explicitly leave some security issues up to the=20 applications to deal with. If the security of something is terribly=20 important to you, you will need to provide heftier application level=20 security mechanisms than Bluetooth provides, *and* ensure that the hardware= =20 platform that you are running on has the computational resources required=20 to service the application. Remember that Bluetooth is, to some degree, a= =20 lowest common denominator. From: Lasse Leskel=E4 Subject: a paper on Bluetooth security There is a paper about Bluetooth security at: From: "Reynolds,Martin" Subj: Bluetooth Security The Bluetooth security system is well documented in the Bluetooth specs. Hold tight for this one: it exchanges secret keys using SAFER+. No, this=20 is not my error. They are serious. You are supposed to use sideband=20 information -- a PIN or a serial number -- to enhance the key that you must= =20 exchange to use SAFER+ in the first place. The only "good" news is that=20 the keys are persistent and the devices only need to do this on first=20 introduction. In a cellphone (the cellphone guys wrote the spec) there is a smart card to= =20 help this process along. Worse, there is no security requirement. Bottom line: it could be worse but, in most hands, Bluetooth security is=20 going to be a mess. From: John Savard Subject: M-134-A Take my word for it: the Friedman patent issued last month is definitely=20 the M-134-A, and not the M-229. This is indicated unambiguously in the=20 abstract of the patent, and in the wording of claim 6, but I'll admit it is= =20 hard even to read the claims. The diagram on page 1 (shown enlarged on page 2) also makes it clear that=20 the keyboard is connected through the rotors to a lamp-board in=20 conventional Hebern (or Enigma) fashion, but the 5-level signal goes to the= =20 5 rotors individually. Starting near the bottom of page 4, the first text page of the patent, we= read: "Now, in all cryptographs based upon the use of rotatable cipher wheels of= =20 the type referred to above, and arranged as indicated, means are embodied=20 within the cryptograph for automatically changing the rotatory portions of the cipher wheels during the course of enciphering or deciphering a=20 message; these means are always of such a nature as to make these changes=20 of a definite and predetermined character...." "The basic feature of my invention of this predictable factor and the=20 provision of a mechanism for displacing the cipher wheels in an entirely=20 irregular, aperiodic manner. This is accomplished by means of the=20 wheel-stepping mechanisms shown as at 4, and operated in the present=20 embodiment by individual magnets which are controlled by the single tape=20 transmitter 5..." (Incidentally, all information in the following is based on openly=20 published sources, including, admittedly, material released in the National= =20 Archives, and hence may be freely used and disseminated. I have not at any= =20 time had exposure to any information covered by security restrictions of a= =20 military or intelligence nature by the government of the United States or=20 any other country.) The distinguishing feature of the M-134-A is that it took the bits of a=20 paper tape as input, and used that input to control the movement of rotors,= =20 and these rotors then encrypted a character in the basic fashion of a=20 Hebern machine. This is mentioned explicitly in the patent. The M-229 and M-228, for different purposes, did exactly the reverse of=20 this. Rotors moved (still with the use of an electrical circuit)=20 conventionally, in the way usually produced by gears, but the rotors were=20 wired to a fixed set of live inputs to produce what were essentially binary= =20 bits as output. In the M-228, these bits were XORed with a teleprinter character, and in=20 the M-229 they were used to control rotor movement in an M-134 (the M-134,= =20 M-134-A, and M-134-T2 were essentially the same machine; the M-134-T1 was=20 the subject of a patent granted on January 28, 1936 (U.S. patent 2,028,772,= =20 as referenced in a Cryptologia article on Friedman's patents). And, of=20 course, the M-134-C is one U.S. Army designation for the famous ECM Mark=20 II, or SIGABA. It should be clear, from the quotes given from the patent, why I am=20 definite about this being the M-134, since the patent clearly refers to the= =20 distinguishing feature of that machine: paper tape as input, a permutation= =20 of the alphabet as output. From: Lance Urbas Subject: Re: Authentica in the Dog House Authentica recognizes that a Frequently Asked Question (FAQ) on its Web=20 site, which correlated the strength of encryption with the security of our= =20 products, was misleading. This FAQ has been removed and we thank Mr.=20 Schneier for pointing this out as well as apologize for using his name=20 without his permission. We recognize that no security products are=20 unbreakable and protecting information after it's been delivered to another= =20 user's computer is not foolproof. However, our goal is not to ensure=20 "absolute" security, but to provide organizations with tools that better=20 manage the risk in sharing digital information. ** *** ***** ******* *********** ************* CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses,=20 insights, and commentaries on computer security and cryptography. To subscribe, visit or send a= =20 blank message to crypto-gram-subscribe@chaparraltree.com. To unsubscribe,= =20 visit . Back issues are=20 available on . Please feel free to forward CRYPTO-GRAM to colleagues and friends who will= =20 find it valuable. Permission is granted to reprint CRYPTO-GRAM, as long as= =20 it is reprinted in its entirety. CRYPTO-GRAM is written by Bruce Schneier. Schneier is founder and CTO of=20 Counterpane Internet Security Inc., the author of "Applied Cryptography,"=20 and an inventor of the Blowfish, Twofish, and Yarrow algorithms. He served= =20 on the board of the International Association for Cryptologic Research,=20 EPIC, and VTW. He is a frequent writer and lecturer on computer security=20 and cryptography. Counterpane Internet Security, Inc. is a venture-funded company bringing=20 innovative managed security solutions to the enterprise. Copyright (c) 2000 by Counterpane Internet Security, Inc.