Forwarded From: Bruce Schneier <schneierat_private> CRYPTO-GRAM February 15, 1999 by Bruce Schneier President Counterpane Systems schneierat_private http://www.counterpane.com A free monthly newsletter providing summaries, analyses, insights, and commentaries on cryptography and computer security. Back issues are available at http://www.counterpane.com. To subscribe or unsubscribe, see below. Copyright (c) 1999 by Bruce Schneier ** *** ***** ******* *********** ************* In this issue: Snake Oil News Counterpane Systems -- Featured Research The Doghouse: WinXFiles Back Doors, Export, and the NSA Intel's Processor ID Comments from Readers ** *** ***** ******* *********** ************* Snake Oil The problem with bad security is that it looks just like good security. You can't tell the difference by looking at the finished product. Both make the same security claims; both have the same functionality. Both might even use the same algorithms: triple-DES, 1024-bit RSA, etc. Both might use the same protocols, implement the same standards, and have been endorsed by the same industry groups. Yet one is secure and the other is insecure. Many cryptographers have likened this situation to the pharmaceutical industry before regulation. The parallels are many: vendors can make any claims they want, consumers don't have the expertise to judge the accuracy of those claims, and there's no real liability on the part of the vendors (read the license you agree to when you buy a software security product). This is not to say that there are no good cryptography products on the market. There are. There are vendors that try to create good products and to be honest in their advertising. And there are vendors that believe they have good products when they don't, but they're just not skilled enough to tell the difference. And there are vendors that are just out to make a quick buck, and honestly don't care if their product is good or not. Most products seem to fall into the middle category: well-meaning but insecure. I've talked about the reason in previous CRYPTO-GRAM essays, but I'll summarize: anyone can create a cryptography product that he himself cannot break. This means that a well-meaning person comes up with a new idea, or at least an idea that he has never heard of, cannot break it, and believes that he just discovered the magic elixir to cure all security problems. And even if there's no magic elixir, the difficulty of creating secure products combined with the ease of making mistakes makes bad cryptography the rule. The term we use for bad cryptography products is "snake oil," which was the turn-of-the-century American term for quack medicine. It brings to mind traveling medicine shows, and hawkers selling their special magic elixir that would cure any ailment you could imagine. For example, here is a paragraph from the most recent snake-oil advertisement I received in e-mail: "Encryptor 4.0 uses a unique in-house developed incremental base shift algorithm. Decryption is practically impossible, even if someone manages to reverse engineer our program to obtain the algorithm, the decryption of a file depends on the exact password (encryption key). Even if someone is guessing the encryption key the file will only be decrypted correctly if the encryption key is 100 percent correct. See the IMPORTANT WARNING on our Web site http://ten4.com/encryptor." I checked the Web site; the odds that this product is any good are negligible. Elsewhere I've talked about building strong security products, using tried-and-true mathematics, and generally being conservative. Here I want to talk about some of the common snake-oil warning signs, and how you can pre-judge products from their advertising claims. These warning signs are not foolproof, but they're pretty good. Warning Sign #1: Pseudo-mathematical gobbledygook. In the quote above, notice the "unique in-house developed incremental base shift algorithm." Does anyone have any idea what that means? Are there any academic papers that discuss this concept? Long noun chains don't automatically imply security. Meganet <http://www.meganet.com> has a beauty on their Web site: "The base of VME is a Virtual Matrix, a matrix of binary values which is infinity in size in theory and therefore have no redundant value. The data to be encrypted is compared to the data in the Virtual Matrix. Once a match is found, a set of pointers that indicate how to navigate inside the Virtual Matrix is created. That set of pointers (which is worthless unless pointing to the right Virtual Matrix) is then further encrypted in dozens other algorithms in different stages to create an avalanche effect. The result is an encrypted file that even if decrypted is completely meaningless since the decrypted data is not the actual data but rather a set of pointers. Considering that each session of VME has a unique different Virtual Matrix and that the data pattern within the Virtual Matrix is completely random and non-redundant, there is no way to derive the data out of the pointer set." This makes no sense, even to an expert. US Data Security <http://www.usdsi.com> has another beauty: "From a mathematical point of view, the TTM algorithm is intuitively natural and less cumbersome to use than methods that are number-theory based." SuperKrypt <http://www.superkrypt.com/> tries to impress with an acronym: "SuperKrypt products utilize the DNGT bulk encryption method," whatever that is. And Cennoid <http://www.cennoid.com> just doesn't understand what it's talking about: "Since key length and key structure vary and since the encryption engine does not use any mathematical algorithms, reverse engineering is impossible and guessing is not an option." The point here is that, like medicine, cryptography is a science. It has a body of knowledge, and researchers are constantly improving that body of knowledge: designing new security methods, breaking existing security methods, building theoretical foundations, etc. Someone who obviously does not speak the language of cryptography is not conversant with the literature, and is much less likely to have invented something good. It's as if your doctor started talking about "energy waves and healing vibrations." You'd worry. Warning Sign #2: New mathematics. Every couple of years, some mathematician looks over at cryptography, says something like, "oh, that's easy," and proceeds to create an encryption algorithm out of whatever he has been working on. Invariably it is lousy. Beware cryptography based on new paradigms or new areas of mathematics: chaos theory, neural networks, coding theory, zeta functions. Cryptography is hard; the odds that someone without any experience in the field can revolutionize it are small. And if someone does, let the academic community have a few years to understand it before buying products based on it. Warning Sign #3: Proprietary cryptography. I promise not to start another tirade about the problems of proprietary cryptography. I just include it here as a warning sign. So when a company like GenioUSA <http://www.geniousa.com/genio/> refuses to divulge what algorithm they're using (they claim it's "world class secret key encryption," whatever that means), you should think twice before using their product (it's completely broken, by the way). Another company, Crypt-o-Text <http://www.savard.com/crypt-o-text/>, promises a "complex proprietary encryption algorithm" and that "there is absolutely no way to determine what password was used by examining the encrypted text." It was completely broken in an InfoWorld review. This kind of thing isn't exclusive to small companies. Axent once tried to pass XOR off as a real encryption algorithm. It wasn't until some peeked inside the compiled code that we discovered it. Any company that won't discuss its algorithms or protocols has something to hide. There's no other possible reason. (And don't let them tell you that it is patent-pending; as soon as they file the patent, they can discuss the technology. If they're still working on the patent, tell them to come back after they can make their technology public.) Warning Sign #4: Extreme cluelessness. Some companies make such weird claims that it's obvious that they don't understand the field. TriStrata says this about their encryption algorithm: "Since TriStrata's encryption scheme is so simple and of such low computational complexity, the client portion can reside on a wide range of systems -- from a server to a portable PC." Don't they realize that every encryption algorithm is small enough to fit on a portable PC, that DES and RSA and SHA can fit on an 8-bit smart card, and that you can implement some of the AES candidates in 17 clock cycles per byte or a few thousand gates? GenioUSA talks about why they don't use public-key cryptography in their product): "Public Key encryption is exactly that, you are not the only party involved in the generation, integrity, and security of all the keys/passwords used to encrypt your e-mail, documents, and files. Public key encryption is great technology to use to exchange things with anyone you won't trust with your secret key(s) and/or can't exchange secret key(s) with. We quote one sentence from a well known Web page, 'All known public key cryptosystems, however, are subject to shortcut attacks and must therefore use keys ten or more times the lengths of those discussed here to achieve the an [sic] equivalent level of security.'" So what? This company just doesn't get it. Warning Sign #5: Ridiculous key lengths. Jaws Technology <http://www.jawstech.com> boasts: "Thanks to the JAWS L5 algorithm's statistically unbreakable 4096 bit key, the safety of your most valued data files is ensured." Meganet takes the ridiculous a step further <http://www.meganet.com>: "1 million bit symmetric keys -- The market offer's [sic] 40-160 bit only!!" Longer key lengths are better, but only up to a point. AES will have 128-bit, 192-bit, and 256-bit key lengths. This is far longer than needed for the foreseeable future. In fact, we cannot even imagine a world where 256-bit brute force searches are possible. It requires some fundamental breakthroughs in physics and our understanding of the universe. For public-key cryptography, 2048-bit keys have same sort of property; longer is meaningless. Think of this as a sub-example of Warning Sign #4: if the company doesn't understand keys, do you really want them to design your security product? Warning Sign #6: One-time pads. One-time pads don't make sense for mass-market encryption products. They may work in pencil-and-paper spy scenarios, they may work on the U.S.-Russia teletype hotline, but they don't work for you. Most companies that claim they have a one-time pad actually do not. They have something they think is a one-time pad. A true one-time pad is provably secure (against certain attacks), but is also unusable. Elementrix, now defunct, announced a one-time pad product a few years ago, and refused to recant when it was shown that it was no such thing. Ciphile Software <http://www.ciphile.com> just tries to pretend: "Original Absolute Privacy - Level3 is an automated pseudo one-time pad generator with very sophisticated and powerful augmenting features." Whatever that means. More recently, TriStrata <http://www.tristrata.com> jumped on the world's cryptography stage by announcing that they had a one-time pad. Since then, they've been thoroughly trounced by anyone with a grain of cryptographic sense and have deleted the phrase from their Web site. At least they've exhibited learning behavior. Ultimate Privacy <http://www.ultimateprivacy.com> might actually use a one-time pad (although they claim to use Blowfish, too, which worries me): "The one time pad is a private key method of encryption, and requires the safe and secure distribution of the pad material, which serves as the key in our solution. The security of the key distribution comes down to how secure you want to be -- for communicating point-to-point with one other person, we suggest a face-to-face hand-off of the pad material." Remember that you need to hand off the same volume of bits as the message you want to send, otherwise you don't have a one-time pad anymore. Warning Sign #7: Unsubstantiated claims. Jaws Technologies says this about its new encryption technology: "This scientifically acclaimed encryption product is the world's strongest commercially available software of its kind." Acclaimed by who? The Web site doesn't say. World's strongest by what comparison? Nothing. UBE98, at <http://www.parkie.ndirect.co.uk/>, stands for "unbreakable encryption," or at least it did before someone took a day to break it. Its Web site makes the same sort of ridiculous claims: "One of the Strongest Encryptions available in the UK in a program that everyone will understand how to use!" Wow. SenCrypt <http://www.ionmarketing.com/> is advertised to be "the most secure cryptographic algorithm known to mankind." Double wow. Some companies claim "military-grade" security. This is a meaningless term. There's no such standard. And at least in the U.S., military cryptography is not available for non-government purposes (although government contractors can get it for classified contracts). Other companies make claims about other algorithms that are "broken," without giving details. Or that public-key cryptography is useless. Don't believe any of this stuff. If the claim seems far-fetched, it probably is. If a company claims that their products have been reviewed by cryptographers, ask for names. Ask for a copy of the review. Counterpane Systems reviews many products, and our clients can give out the reviews if they choose. Warning Sign #8: Security proofs. There are two kinds of snake-oil proofs. The first are real mathematical proofs that don't say anything about real security. The second are fake proofs. Meganet claims to have a proof that their VME algorithm is as secure as a one-time pad. Their "proof" is to explain how a one-time pad works, add the magic spell "VME has the same phenomenon behavior patterns, hence proves to be equally strong and unbreakable as OTP," and then give the results of some statistical tests. This is not a proof. It isn't even close. More subtle are actual provably secure systems. They do exist. Last summer, IBM made a big press splash about their provably secure system, which they claimed would revolutionize the cryptography landscape. (See <http://www.counterpane.com/crypto-gram-9809.html#cramer-shoup> for a discussion.) Since then, the system has disappeared. It's great research, but mathematical proofs have little to do with actual product security. Warning Sign #9: Cracking contests. I wrote about this at length last December: <http://www.counterpane.com/crypto-gram-9812.html#contests>. For now, suffice it to say that cracking contests are no guarantee of security, and often mean that the designers don't understand what it means to show that a product is secure. Conclusion: Separating the Good from the Bad These snake-oil warning signs are neither necessary nor sufficient criteria for separating the good cryptography from the snake oil. Just as there could be insecure products that don't trigger any of these nine warning signs, there could be secure products that look very much like snake oil. But most people don't have the time, patience, or expertise to perform the kind of analysis necessary to make an educated determination. In the absence of a Food-and-Drug-Administration-like body to regulate cryptography, the only thing a reasonable person can do is to use warning signs like these as guides. Further reading: The "Snake Oil" FAQ is an excellent source of information on questionable cryptographic products, and a good way to increase the sensitivity of your bullshit detector. Get your copy at: <http://www.interhack.net/people/cmcurtin/snake-oil-faq.html>. ** *** ***** ******* *********** ************* News The U.S. has new interim cryptography export regulations. The Department of Commerce issued new interim regulations on encryption export controls on December 31, 1998. Products with DES can now be freely exported. (Of course, we all know that DES can be broken in 21 hours by a bunch of amateurs, and a lot faster by professionals.) Products with any key length can be exported to insurance companies, medical end-users, and online merchants (only for buying and selling goods), under the current exception available for banks. Corporations can export to their subsidiaries for "internal company proprietary use"; some of this extends to partners of American companies. Some of the licensing requirements on export of key escrow/key recovery systems have been removed. These new regulations, announced in September, are targeted towards large corporations. Restrictions on the exports of strong encryption used for private, non-commercial reasons is still strictly limited. Comments on the rules are due March 1, 1998. A copy of the rules is available at: http://www.epic.org/crypto/export_controls/bxa-regs-1298.html France reversed its long-standing position as being one of the most anti-cryptography countries in the world. On January 19, Prime Minister Lionel Jospin announced the French government is relaxing its current restrictive policy on encryption. Under the new policy, a key escrow system of "Trusted Third Parties" will no longer be required for domestic use, the 1996 law requiring TTPs will not be implemented, and users will be able to use up to 128-bit encryption without restrictions until a new law which eliminates all restrictions is enacted. Rah rah. The announcement is available in French at: http://www.premier-ministre.gouv.fr/PM/D190199.HTM http://www.internet.gouv.fr/francais/textesref/cisi190199/decis1.htm http://www.internet.gouv.fr/francais/textesref/cisi190199/decis2.htm and a translation is at: http://slashdot.org/articles/99/01/19/1255234.shtml In addition to adding a unique processor ID (see below) to its Pentium III chip, Intel is adding a hardware random number generator. This is excellent news. I know nothing about how it works (or even if it is any good), but using techniques such as Yarrow, we can take even a mediocre hardware random number generator and turn it into something that is good for cryptographic applications. There's a new Word-based virus named Caligula. Caligula steals a user's PGP key ring and sends it to the creators' FTP site. According to Network Associates (owners of PGP, having bought it in 1997), this doesn't compromise PGP security because the key ring file is useless without the passphrase. This seems a bit optimistic; once the private key ring is known, PGP's security level goes from unbreakable to that of a standard hashed passphrase. And most people choose lousy passphrases. http://www.techweb.com/wire/story/TWB19990205S0011 Sun's Scott McNealy announced that we all have no privacy anyway, and might as well get used to it. All the more troubling, Sun is a member of the Online Privacy Alliance. With an attitude like McNealy's, is it hard to believe that "an industry coalition that seeks to head off government regulation of online consumer privacy in favor of an industry self-regulation approach" has my best interests at heart? http://www.wired.com/news/news/politics/story/17538.html SECRET POWER is an excellent book about project Echelon, the NSA's secret program designed to eavesdrop on pretty much every piece of communication in the world. The book isn't available in the U.S. (Amazon.com never heard of it, and I got my copy from a friend in New Zealand), but CovertAction Quarterly has an excellent article on the topic by the author: http://www.caq.com/caq59/CAQ59GlobalSnoop.html And if you want to try to get the book, here are the details: Nicky Hager, SECRET POWER, Craig Potton Publishing (Box 555, Nelson, New Zealand), 1996. See also: http://www.gn.apc.org/duncan/echelon-dc.htm ** *** ***** ******* *********** ************* Counterpane Systems -- Featured Research "Breaking Up Is Hard To Do: Modeling Security Threats for Smart Cards" B. Schneier and A. Shostack, First USENIX Symposium on Smart Cards, USENIX Press, to appear. Smart card systems differ from conventional computer systems in that different aspects of the system are not under a single trust boundary. The processor, I/O, data, programs, and network may be controlled by different, and hostile, parties. We discuss the security ramifications of these "splits" in trust, showing that they are fundamental to a proper understanding of the security of systems that include smart cards. http://www.counterpane.com/smart-card-threats.html ** *** ***** ******* *********** ************* The Doghouse: WinXFiles WinXFiles <http://www.pepsoft.com/wxf/intro.html> is an image viewer that claims security. Quoting from the Web site, "WinXFiles(tm) with its attractive tabbed-dialog interface features secure encryption to prevent unauthorized access of all type (sic) of files and particularly of your image collection." While it may have an attractive interface, it is anything but secure. WinXFiles obscures the password and stores it in the header of the encrypted file. It obscures the password by adding it (modulo 256) to the output of a pseudorandom number generator. The PRNG is seeded with one byte derived from the password (simply the sum of the characters in the password modulo 255). The PRNG itself is also laughably weak; it generates two bytes at a time by adding and subtracting the offset from the seed byte, respectively. Perhaps the scariest thing about the encryption is the high ratings it got from reviewers: http://www.pepsoft.com/wxf/reviews.html. (This work was done by Mike Stay and Casimir, a French hacker whose exploits have been reported by Joe Peschel. Thanks to Mike Stay for writing this up.) ** *** ***** ******* *********** ************* Back Doors, Export, and the NSA Among cryptography product companies, "Have you had a meeting with Lew Giles?" is code for "Has the NSA asked you to secretly weaken your product?" Giles has been known to visit companies and request that they add back doors to their products so that the NSA could break the encryption. The deal went something like this: Giles offered you preferential treatment for export if you would add a back door. The back door could be subtle enough that it wouldn't show up in the design, and only be obvious if someone analyzed the binary code. It could be something that would easily be viewed as a mistake if someone learned about it. Maybe you could weaken your random number generator, or leak a few key bits in a header. Anything that would let the NSA decrypt the ciphertext without it looking like the crypto was broken. In return you would be able to export your products. But you and he would have to come up with some kind of cover story as to why you could export what was normally unexportable encryption, something that would allay any suspicion. Giles was supposedly very smooth. He would try a variety of tactics to make you go along with this plan. Sometimes he would meet with just the engineers -- no management -- to try and circumvent potential problems. I've heard this story from several cryptography companies, large and small. None of them were willing to talk on the record. All were visited at least two years ago; most were visited by Giles. None agreed to this bargain. (Presumably those who did would be unwilling to admit even talking to the NSA.) And all of these stories are at least two years old; I have no idea if Giles is still employed by the NSA, if he is still doing this kind of thing, or in fact if anyone is still doing this kind of thing. None of this should be surprising. The NSA seems to have done whatever it could to add trap-doors into cryptography products. They completely subverted the Swiss company CryptoAG, for example, and for at least half a century have been intercepting and decrypting the top-secret documents of most of the world's governments. (The URL for this absolutely fascinating story is <http://www.caq.com/CAQ/caq63/caq63madsen.html>.) This kind of thing happens in Canada, too. One name I've heard is Norm Weijer; a couple of years ago he visited several Canadian crypto companies. One person tells the story of submitting his product to Norm for export approval. The product used a number of different proprietary algorithms, all weakened to 40-bit. The word came back, unofficially of course, that if he would get rid of the proprietary algorithms and replace them with 56-bit DES, they could get export approval. Presumably using their existing DES crackers was easier than building unique crackers for this particular product. ** *** ***** ******* *********** ************* Intel's Processor ID Last month Intel Corp. announced that its new processor chips would come equipped with ID numbers, a unique serial number burned into the chip during manufacture. Intel said that this ID number will help facilitate e-commerce, prevent fraud and promote digital content protection. Unfortunately, it doesn't do any of these things. To see the problem, consider this analogy: Imagine that every person was issued a unique identification number on a national ID card. A person would have to show this card in order to engage in commerce, get medical care, whatever. Such a system works, provided that the merchant, doctor, or whoever can examine the card and verify that it hasn't been forged. Now imagine that the merchants were not allowed to examine the card. They had to ask the person for his ID number, and then accept whatever number the person responded with. This system is only secure if you trust what the person says. The same problem exists with the Intel scheme. Yes, the processor number is unique and cannot be changed, but the software that queries the processor is not trusted. If a remote Web site queries a processor ID, it has no way of knowing whether the number it gets back is a real ID or a forged ID. Likewise, if a piece of software queries its processor's ID, it has no way of knowing whether the number it gets back is the real ID or whether a patch in the operating system trapped the call and responded with a fake ID. Because Intel didn't bother creating a secure way to query the ID, it will be easy to break the security. As a cryptographer, I cannot design a secure system to validate identification, enforce copy protection, or secure e-commerce using a processor ID. It doesn't help. It's just too easy to hack the software that queries the hardware. This kind of system puts us in the same position we were in when the government announced the Clipper chip: Those who are engaged in illicit activities will subvert the system, while those who don't know any better will find their privacy violated. I predict that patches that randomize the ID number will be available on hacker Web sites within days of the new chips hitting the streets. The only positive usage for processor IDs is the one usage that Intel said they would not do: stolen processor tracking. Pentium II chips are so valuable that trucks are hijacked on the highways, sometimes resulting in drivers being killed. A database of stolen processor IDs would drop the market for stolen CPUs to zero: board manufacturers, computer companies, resellers and customers could simply query the database to ensure that their particular CPU wasn't stolen. (This is the primary usage for automobile VINs.) This same system could be used to prevent manufacturers from overclocking their CPUs -- running them faster than Intel rated them for -- another thing that Intel would love to prevent. The real question is whether computers are a dangerous technology, and need to be individually tracked like handguns and automobiles. During the Cold War many Eastern European countries required mimeograph machines to be individually licensed; I have a hard time believing that computers need the same sorts of controls. http://www.techweb.com/wire/story/TWB19990120S0017 http://cnn.com/TECH/computing/9901/22/intelid.idg/index.html http://www.semibiznews.com/stories99/jan99y/9a22intID.htm The boycott: http://www.crn.com/dailies/weekending012999/jan25dig15.asp Intel's partially backing down: http://cbs.marketwatch.com/archive/19990125/news/current/intc.htx?source=htx /http2_mw http://www.pcworld.com/pcwtoday/article/0,1510,9497,00.html This article originally appeared in: http://www.zdnet.com/zdnn/stories/comment/0,5859,2194863,00.html Since I wrote the above essay, there have been some developments. Intel announced that the Pentium III would be shipped with the feature turned off. This doesn't help one bit. Intel has also dropped rumors about a secure protocol running in tamper-resistant software that will query the ID number in a secure manner. This doesn't make sense: there's no such thing as tamper resistant software (ask anyone who breaks copy protection schemes as a hobby) and the real worry is the unauthorized protocols that will query, or hide, the ID number. Also, people have pointed out that there are other unique ID numbers on your computer: Ethernet cards, hard drive serial numbers, etc. This is true, and could be a problem, but Intel intends to use its ID number as a surveillance feature. http://www.techweb.com/se/directlink.cgi?EET19990201S0020 Intel's response to all of this is here: http://support.intel.com/support/processors/pentiumiii/psqa.htm ** *** ***** ******* *********** ************* Comments from Readers From: kragenat_private (Kragen Sitaker) Subj: Side Channel Attacks When I build a computer system, hardware and software, to solve some problem, I only need to ensure that there exists some reasonable set of circumstances under which it does what it's supposed to do. If a client mounts a standard PC in an enclosure with 150-degree heat, or cuts off power to it at unpredictable times, or whatever, and then they bitch at me that it broke, I can blame them. After all, I never claimed it would work under those conditions. When I build a security system, I need to ensure that there does not exist any reasonable set of circumstances under which it does not do what it's not supposed to do, as well. If my smart card leaks information when it's operated out of spec, well, I can't blame the customer for operating it out of spec, can I? :) The dichotomy is deep. In one case, we need only ensure that \exists X: Y(X) = T, where Y(X) means "property Y holds true under circumstances X". In the other case, we must ensure that \not\exists X: Y(X) = F, or equivalently \forall X: Y(X) = T. Most computers and software are designed to fit the first case. In this case, the solution to the discovery of a buffer overflow is to tell the user not to do that -- or if they must do that, to expand the buffer. In the second case, the solution is to check bounds carefully. The result: when software designed for the first environment is pressed into service in the second, it's full of holes. The same is true of hardware, and even hardware design methodologies. From: Bob Geiger <geigerat_private> Subj: Internet attacks One of the important points is how the Internet changes the standard attack cost/distance model. Given a value of X it would take an attacker Y dollars to break into my physical world stuff. The farther the attacker must travel in physical space the higher the cost to him. So unless you have the Hope Diamond in your basement you can probably assume criminals will be drawn from a limited pool. Furthermore they actually have to purchase tools and the threat of being caught (or shot) is a real one. Now in the Internet this cost/distance ratio is gone. Suddenly anyone, anywhere, can attack your systems. Furthermore the availability of free tools limits the investment required, and the difficulty in tracking down attackers compounds the problem. Another problem is that when it becomes easy and relatively risk free to poke around so many systems information deemed of limited value may add up to help in breaking into much more valuable systems. So we end up needing a far, far greater level of security as related to system value than in "physical space". I think many people have a hard time understanding this difference and this is why warnings on Internet security are sometimes viewed as alarmist. ** *** ***** ******* *********** ************* CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, insights, and commentaries on cryptography and computer security. To subscribe, visit http://www.counterpane.com/crypto-gram.html or send a blank message to crypto-gram-subscribeat_private To unsubscribe, visit http://www.counterpane.com/unsubform.html. Back issues are available on http://www.counterpane.com. Please feel free to forward CRYPTO-GRAM to colleagues and friends who will find it valuable. Permission is granted to reprint CRYPTO-GRAM, as long as it is reprinted in its entirety. CRYPTO-GRAM is written by Bruce Schneier. Schneier is president of Counterpane Systems, the author of "Applied Cryptography," and an inventor of the Blowfish, Twofish, and Yarrow algorithms. He served on the board of the International Association for Cryptologic Research, EPIC, and VTW. He is a frequent writer and lecturer on cryptography. Counterpane Systems is a six-person consulting firm specializing in cryptography and computer security. Counterpane provides expert consulting in: design and analysis, implementation and testing, threat modeling, product research and forecasting, classes and training, intellectual property, and export consulting. Contracts range from short-term design evaluations and expert opinions to multi-year development efforts. http://www.counterpane.com/ Copyright (c) 1999 by Bruce Schneier -o- Subscribe: mail majordomoat_private with "subscribe isn". Today's ISN Sponsor: Internet Security Institute [www.isi-sec.com]
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:19:12 PDT