|
|
electronic snake oil
by Matt Curtin
Curtin is a hacker for hire, focusing on the areas of network
computing, security, and open operating systems. When not cleaning his
white hat, he likes to build houses out of his ever-growing collection
of old business cards.
So your company has finally decided to heed the advice you gave them 11 years ago, and they're going to start using email to communicate with business partners. Or, more likely, they've already been doing that, but now they have concerns about the security of doing so. Specifically, they don't want competitors reading the memos that are going back and forth. Or maybe you're sending email to your aunt Lena who lives in Russia and you don't think what you have to tell her is the business of anyone at Ft. Meade. Or your company has a number of small offices around the country that you want to tie together through a virtual private network (VPN) over the Internet. In any of these cases, you have a generic need to send data to another party privately. You need to lock your data. You need cryptography. But how does a system administrator, or some other technical person who isn't a cryptographer, know the difference between a good cryptography product and the stuff of Cracker Jack secret decoder rings? The short answer is that there isn't any really easy answer. However, over the years, a few common practices have developed that have helped us identify the traits of those whose products are "snake oil." Before we consider those, though, let's cover some terminology and basic concepts of cryptography. Snake Oil and Silver Bullets Why "snake oil"? In many fields, the term is used to denote something sold without consideration of its quality or its ability to fulfill its vendor's claims. This term originally applied to elixirs sold in traveling medicine shows. The salesmen would claim their elixir would cure just about any ailment that a potential customer could have. Listening to the claims made by some crypto vendors, "snake oil" is a surprisingly apt name. Basic Concepts A wide variety of information on cryptography is available. There is the USENET Cryptography FAQ, RSA's Cryptography Today FAQ, and books such as Bruce Schneier's excellent Applied Cryptography[1]. When evaluating any product, be sure to understand your needs. For data-security products, what are you trying to protect? Do you want a data archiver, an email plug-in, or something that encrypts online communications? Do you need to encrypt an entire disk or just a few files? And how secure is secure enough? Does the data need to be unreadable by "spies" for five minutes, one year, or 100 years? Is the spy someone's kid sister, a corporation, or a government? Symmetric versus Asymmetric CryptographyThere are two basic types of cryptosystems: symmetric (also known as "conventional" or "secret key") and asymmetric ("public key"). Symmetric ciphers require both the sender and the recipient to have the same key. This key is used by the sender to encrypt the data and again by the recipient to decrypt the data. The problem here is getting the sender and recipient to share the key. Asymmetric ciphers are much more flexible from a key-management perspective. Each user has a pair of keys: a public key and a private key. Messages encrypted with one key can only be decrypted by the other key. The public key can be published widely, while the private key is kept secret. So if Alice wishes to send Bob some secrets, she simply finds and verifies Bob's public key, encrypts her message with it, and mails it off to Bob. When Bob gets the message, he uses his private key to decrypt it. Verification of public keys is an important step. Failure to verify that the public key really does belong to Bob leaves open the possibility that Alice is using a key whose associated private key is in the hands of an enemy. Asymmetric ciphers are much slower than their symmetric counterparts. Also, key sizes generally must be much larger. Secrecy versus Integrity: What Are You Trying to Protect?For many users of computer-based crypto, preserving the contents of a message is as important as protecting its secrecy. Damage caused by tampering can often be worse than damage caused by disclosure. For example, it may be disquieting to discover that a cracker has read the contents of your funds-transfer authorization, but it's a disaster for him to change the transfer destination to his own account. Encryption by itself does not protect a message from tampering. In fact, there are several techniques for changing the contents of an encrypted message without ever figuring out the encryption key. If the integrity of your messages is important, don't rely on secrecy alone to protect them. Check how the vendor protects messages from undetected modification. Key SizesEven if a cipher is secure against analytical attacks, it will be vulnerable to brute-force attacks if the key is too small. In a brute-force attack, the attacker simply tries every possible key until the right one is found. How long this takes depends on the size of the key, how computationally intensive the encryption (or decryption) process is, and the amount of processing power available. So when trying to secure data, you need to consider how long it must remain secure and how much computing power an attacker can use. Some guidelines have been offered for choosing an appropriate key length. For instance, Table 1 shows the cost of breaking symmetric keys by brute force, as noted by Blaze et al.[2]. This report strongly recommends using symmetric keys of 90 bits or more.
Table 1: Time and Cost of Key Recovery
With the tremendous increases in computing power over the last several decades, cryptosystems once considered secure are now vulnerable to brute-force attacks. RSA Laboratories sponsored a series of contests, collectively known as the 1997 Secret Key Challenge[5]. So far, we have seen RC5 up to 56 bits fall victim to brute-force attacks, as well as the financial industry's workhorse, DES. At 56 bits, the keys used for DES are just too small to stand up to a dedicated attacker. It's noteworthy that both of the first two groups to break a DES-encrypted message did so with essentially no funding. The Electronic Frontier Foundation funded a third break, performed with a special-purpose DES-cracking machine, "Deep Crack," which did the job in 56 hours. If small nonprofit groups can fund development of a machine like Deep Crack, certainly the power that exists in larger for-profit organizations, organized crime, and government intelligence agencies can go well beyond 56 bits.
Table 2. Key Lengths with Similar Resistance to Brute-Force Attacks
As mentioned earlier, asymmetric ciphers typically require significantly longer keys to provide the same level of security as symmetric ciphers. Comparing key lengths between algorithms is awkward because different algorithms have different characteristics. Knowing the key size is useless if you don't know what type of algorithm is being used. But to give you some idea of what's reasonable, Table 2 [1] compares symmetric keys against one type of asymmetric key: those based on the "factoring problem" or the "discrete log problem." (Algorithms based on the "elliptical curve discrete log problem" are more resistant to brute-force attacks and can use much smaller keys. In fact, they don't have to be much larger than symmetric keys, as far as is known now.) Keys versus PassphrasesA "key" is not the same thing as a "passphrase" or "password." In order to resist attack, all possible keys must be equally probable. If some keys are more likely to be used than others, then an attacker can use this information to reduce the work needed to break the cipher. Essentially, a key must be random. However, a passphrase generally needs to be easy to remember, so it has significantly less randomness than its length suggests. For example, a 20-letter English phrase, rather than having 20 x 8 = 160 bits of randomness, only has about 20 x 2 = 40 bits of randomness. So, most cryptographic software will convert a passphrase into a key through a process called "hashing" or "key initialization." Avoid cryptosystems that skip this phase by using a password directly as a key. Avoid anything that doesn't let you generate your own keys (e.g., the vendor sends you keys in the mail, or keys are embedded in the copy of the software you buy). Implementation EnvironmentOther factors that can influence the relative security of a product are related to its environment. For example, in software-based encryption packages, is there any plaintext that's written to disk (perhaps in temporary files)? What about operating systems that have the ability to swap processes out of memory onto disk? When something to be encrypted has its plaintext counterpart deleted, is the extent of its deletion a standard removal of its name from the directory contents, or has it been written over? If it's been written over, how well has it been written over? Is that level of security an issue for you? Are you storing cryptographic keys on a multi-user machine? If so, the likelihood of having your keys illicitly accessed is much higher. It's important to consider such things when trying to decide how secure something you implement is (or isn't) going to be. Snake Oil Warning Signs "Trust Us, We Know What We're Doing"Perhaps the biggest warning sign of all is the "trust us, we know what we're doing" message that's either stated directly or implied by a vendor. If the vendor is concerned about the security of their system after describing exactly how it works, it is certainly worthless. Regardless of whether or not they tell, smart people will be able to figure it out. The bad guys after your secrets (especially if you are an especially attractive target, such as a large company, bank, etc.) are not stupid. They will figure out the flaws. If the vendor won't tell you exactly and clearly what's going on inside, you can be sure that they're hiding something, and that the only one to suffer as a result will be you, the customer. TechnobabbleIf the vendor's description appears to be confusing nonsense, it might very well be so, even to an expert in the field. One sign of technobabble is a description that uses newly invented terms or trademarked terms without actually explaining how the system works. Technobabble is a good way to confuse a potential user and to mask the vendor's own lack of expertise. And consider this: If the marketing material isn't clear, why expect the instruction manual to be any better? Even the best product can be useless if it isn't applied properly. If you can't understand what a vendor is saying, you're probably better off finding something that makes more sense. Secret AlgorithmsAvoid software that uses secret algorithms. This is not a safe means of protecting data. If the vendor isn't confident that its encryption method can withstand scrutiny, then you should be wary of trusting it. A common excuse for not disclosing an algorithm is that "hackers might try to crack the program's security." While this may be a valid concern, it should be noted that such "hackers" can reverse-engineer the program to see how it works anyway. This is not a problem if the algorithm is strong and the program is implemented properly. Using a well-known trusted algorithm, providing technical notes explaining the implementation, and making the source code available are signs that a vendor is confident about its product's security. You can take the implementation apart and test it yourself. Even if the algorithm is good, a poor implementation will render a cryptography product completely useless. However, a lock that attackers can't break even when they can see its internal mechanisms is a strong lock indeed. Good cryptography is exactly this kind of lock. Note that a vendor who specializes in cryptography may have a proprietary algorithm that it will reveal only under a nondisclosure agreement. The crypto product may be perfectly adequate if the vendor is reputable. (But how does a nonexpert know if a vendor is reputable in cryptography?) In general, you're best off avoiding secret algorithms. Revolutionary BreakthroughsBeware of any vendor who claims to have invented a "new type of cryptography" or a "revolutionary breakthrough." True breakthroughs are likely to show up in research literature, and professionals in the field typically won't trust them until after years of analysis, when they're not so new anymore. The strength of any encryption scheme is only proven by the test of time. New crypto is like new pharmaceuticals, not new cars. And in some ways it's worse: If a pharmaceutical company produces bogus drugs, people will start getting sick, but if you're using bogus crypto, you probably won't have any indication that your secrets aren't as secret as you think. Avoid software that claims to use "new paradigms" of computing such as cellular automata, neural nets, genetic algorithms, chaos theory, etc. Just because software uses a different method of computation, it isn't necessarily more secure. (In fact, these techniques are the subject of ongoing cryptographic research, and nobody has published successful results based on their use yet.) Also be careful of specially modified versions of well-known algorithms. This may intentionally or unintentionally weaken the cipher. It's important to understand the difference between a new cipher and a new product. Engaging in the practice of developing both ciphers and cryptographic products is a fine thing to do. However, to do both at the same time is foolish. Many snake-oil vendors brag about how they do this, despite the lack of wisdom in such activity. Experienced Security Experts, Rave Reviews, and Other Useless CertificatesBeware of any product that claims it was analyzed by "experienced security experts" without providing references. Always look for the bibliography. Any cipher that they're using should appear in a number of scholarly references. If not, it's obviously not been tested well enough to prove or disprove its security. Don't rely on reviews from newspapers, magazines, or television shows, since they generally don't have cryptographers to analyze software for them. (Celebrity "hackers" who know telephone systems are not necessarily crypto experts.) The fact that a vendor is a well-known company or the algorithm is patented doesn't make it secure either. UnbreakabilitySome vendors will claim their software is "unbreakable." This is marketing hype and a common sign of snake oil. No algorithm is unbreakable. Even the best algorithms are susceptible to brute-force attacks, though this can be impractical if the key is large enough. Some companies that claim unbreakability actually have serious reasons for saying so. Unfortunately, these reasons generally depend on some narrow definition of what it means to "break" security. For example, one-time pads (see the next section) are technically unbreakable as far as secrecy goes, but only if several difficult and important conditions are true. Even then, they are trivially vulnerable to known plaintext attacks on the message's integrity. Other systems may be unbreakable only if one of the communicating devices (such as a laptop) isn't stolen. So be sure to find out exactly what the "unbreakable" properties of the system are, and see if the more breakable parts of the system also provide adequate security. Often, less-experienced vendor representatives will roll their eyes and say, "Of course it's not unbreakable if you do such-and-such." The point is that the exact nature of "such and such" will vary from one product to another. Pick the one that best matches your operational needs without sacrificing your security requirements. One-Time PadsA vendor might claim the system uses a one-time-pad (OTP), which is provably unbreakable. Technically, the encrypted output of an OTP system is equally likely to decrypt to any same-size plaintext. For example,
has an equal chance of decrypting to any of these:
Snake-oil vendors will try to capitalize on the known strength of an OTP. But it is important to understand that any variation in the implementation means that it is not an OTP and has nowhere near the security of an OTP. An OTP system works by having a "pad" of random bits in the possession of both the sender and recipient, but absolutely no one else. Originally, paper pads were used before general-purpose computers came into being. The pad must be sent from one party to the other securely, such as in a locked briefcase handcuffed to the carrier. To encrypt an n-bit message, the next n bits in the pad are used as a key. After the bits are used from the pad, they're destroyed and can never be used again. The bits in the pad cannot be generated by an algorithm or cipher. They must be truly random, using a real random source such as specialized hardware or radioactive decay timings. Some snake-oil vendors will try to dance around this issue and talk about functions they perform on the bit stream, things they do with the bit stream versus the plaintext, or something similar. But this still doesn't change the fact that anything that doesn't use real random bits is not an OTP. The important part of an OTP is the source of the bits, not what one does with them. OTPs are seriously vulnerable if you ever reuse a pad. For instance, the NSA's VENONA project[4], without the benefit of computer assistance, managed to decrypt a series of KGB messages encrypted with faulty pads. It doesn't take much work to crack a reused pad. The real limitation to practical use of OTPs is the generation and distribution of truly random keys. You have to distribute at least one bit of key for every bit of data transmitted. So OTPs are awkward for general-purpose cryptography. They're only practical for extremely low-bandwidth communication channels where two parties can exchange pads with a method different from what they use to exchange messages. (It is rumored that a link from Washington, D.C., to Moscow was encrypted with an OTP.) Further, if pads are provided by a vendor, you cannot verify the quality of the pads. How do you know the vendor isn't sending the same bits to everyone? Keeping a copy for themselves? Or selling a copy to your rivals? Also, some vendors may try to confuse random-session keys or initialization vectors with OTPs. Algorithm or Product X is InsecureBe wary of anything that claims that competing algorithms or products are insecure, without providing evidence for these claims. Sometimes attacks are theoretical or impractical, requiring special circumstances or massive computing power over many years, and it's easy to confuse a layman by mentioning these. Recoverable KeysIf there is a key-backup or key-escrow system, are you in control of the backup or does someone else hold a copy of the key? Can a third party recover your key without much trouble? Remember, you have no security against someone who has your key. If the vendor claims it can recover lost keys without using some type of key-escrow service, avoid it. The security is obviously flawed. Exportable from the USIf the software is made in the US, can it be exported? Strong cryptography is considered dangerous munitions by the United States and requires approval from the US Bureau of Export Administration, under the US Department of Commerce, before it can leave the country. Various interested government agencies serve as consultants to the Bureau of Export Administration when evaluating such requests. (The US isn't alone in this; some other nations have similar export restrictions on strong cryptography.) Chances are, if the software has been approved for export, the algorithm is weak or crackable. If a vendor is unaware of export restrictions, avoid its software. For example, if it claims that the IDEA cipher can be exported, when most vendors (and the US Government!) do not make such a claim, then the vendor is probably lacking sufficient clue to provide you with good cryptography. Because of export restrictions, some decent crypto products come in two flavors: US-only and exportable. The exportable version will be crippled, probably by using smaller keys, making it easy to crack. There are no restrictions on importing crypto products into the US, so a non-US vendor can legally offer a single, secure version of a product for the entire world. Note that a cryptosystem may not be exportable from the US even if it is available outside the US. Sometimes a utility is illegally exported and posted on an overseas site. "Military Grade"Many crypto vendors claim their system is "military grade." This is a meaningless term, since there isn't a standard that defines "military grade," other than being in use by armed forces. Since these organizations don't reveal what crypto they use, it isn't possible to prove or disprove that something is "military grade." Unfortunately, some good crypto products also use this term. Watch for this in combination with other snake-oil indicators, such as "our military-grade encryption system is exportable from the US!" Other Considerations Avoid vendors who don't seem to understand anything described in the "Basic Concepts" section above. Avoid anything that allows someone with your copy of the software to access files, data, etc., without needing some sort of key or passphrase. Beware of products that are designed for a specific task, such as data archiving, and have encryption as an additional feature. Typically, it's better to use an encryption utility for encryption, rather than some tool designed for another purpose that adds encryption as an afterthought. No product is secure if used improperly. You can be the weakest link in the chain if you use a product carelessly. Do not trust any product to be foolproof, and be wary of any product that claims it is. Interface isn't everything; user-friendliness is important, but be wary of anything that puts too much emphasis on ease of use without due consideration to cryptographic strength. Glossary algorithm A procedure or mathematical formula. Cryptographic algorithms convert plaintext to and from ciphertext. cipher Synonym for "cryptographic algorithm" escrow A third party able to decrypt messages sent from one person to another. Although this term is often used in connection with the US Government's "Clipper" proposals, it isn't limited to government-mandated ability to access encrypted information at will. Some corporations might wish to have their employees use cryptosystems with escrow features when conducting the company's business, so the information can be retrieved should the employee be unable to unlock it himself later (if he were to forget his passphrase, suddenly quit, get run over by a bus, etc.) Or, someone might wish her spouse or lawyer to be able to recover encrypted data, etc., in which case she could use a cryptosystem with an escrow feature. initialization vector One of the problems with encrypting such things as files in specific formats (i.e., that of a word processor, email, etc.) is that there is a high degree of predictability about the first bytes of the message. This could be used to break the encrypted message more easily than by brute force. In ciphers where one block of data is used to influence the ciphertext of the next (such as CBC), a random block of data is encrypted and used as the first block of the encrypted message, resulting in a less predictable ciphertext message. This random block is known as the initialization vector. The decryption process also performs the function of removing the first block, resulting in the original plaintext. key A piece of data that, when fed to an algorithm along with ciphertext, will yield plaintext (or, when fed to an algorithm along with plaintext, will yield ciphertext). References [1] B. Schneier. Applied Cryptography, 2d edition. John Wiley & Sons. 1996. [2] M. Blaze, W. Diffie, R. L. Rivest, B. Schneier, T. Shimomura, E. Thompson, M. Wiener. "Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security." Available at <ftp://ftp.research.att.com/dist/mab/keylength.ps> and <http://theory.lcs.mit.edu/~rivest/bsa-final-report.ascii>.
[3] The Crypt Cabal. Cryptography FAQ. Available at [4] The National Security Agency. The VENONA Project. Available at <http://www.nsa.gov/docs/venona/venona.html>. [5] RSA Data Security, Inc. 1997 Secret Key Challenge. Available at <http://www.rsa.com/rsalabs/97challenge/>.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Need help? Use our Contacts page.
First posted: 14 Apr. 1999 jr Last changed: 14 Apr. 1999 jr |
|
Issue index