There's a story covering crypto in this weeks' InfoWorld Electric. Since it's a members-only thing, I'll include the text here, as well as my response to it. I'm hoping that they'll take the article down and take up my offer to provide a better replacement. I suspect that the problem here is that someone was given a subject and a deadline, and told to "go for it." The requisite background for getting clued on crypto is probably significantly longer than the amount of time allowed by the deadline. I suspect that the issue was further clouded by the crypto-clued people she talked to during the research speaking directly about what they're doing, without giving any sort of analogies to make the ideas click and make sense. I hope that my illustration of the bicycle lock serves to clear up the confusion... In any event, we've all got a lot of work to do. I think we should take it upon ourselves to not only talk about crypto and why it's such a Good Thing(tm), but also to *educate* people to help them understand what in the world we're talking about. -matt ------------------------ begin silly article ------------------------- [Image] [PageOne] [Search] [Reader Service] [Ads Services] [Overview Map] [Todays News Logo] [Opinions] [Forums] [Test Center] [Calendar] [This Week In Print[Week In Review] Encryption technology can help secure private data over public carriers, but tackling its own issues is another story By Julie Bort InfoWorld Electric Think about this: Every time one of your end-users sends an electronic communication from your network, it opens the door to an attack. It is unbelievably easy for a knowledgeable hacker to exploit the failings of SMTP and other communications protocols to eavesdrop on Internet e-mail, send phony messages, or even gain access to other networked systems, security consultants say. A domain name or single IP address is the only information needed, and from there the door is wide open for other mischief. One increasingly popular way to plug this gaping hole is to encrypt e-mail and other electronic communications. Encryption is a way to encode text using complex mathematical algorithms. "When explaining encryption, I like to use the analogy of the Cap'n Crunch Super Secret Decoder Rings. These rings [distributed in Cap'n Crunch cereal boxes in the 1960s] contained a very simple algorithm. It was something like `take a letter then add 5.' So an A became an F. Simply speaking, that's all these algorithms are, mathematical formulas," explains Gary Fresen, a member of the American Bar Association's committee on digital signatures and an attorney and partner at Baker McKenzie LLP, in Chicago, one of the world's largest law firms. Although no encryption algorithm is in and of itself crack-proof, several of them are so complex that they are virtually unbreakable. Coupled with proper implementation, authentication, and secure connections, encryption solutions can add a high level of security to any company's arsenal. However, it is an area that requires a knowledgeable person to make the purchasing decision because the technology is very complex, the best product selected will add a level of administration overhead, and numerous industry consortiums are developing competing APIs. NUMEROUS USES. Is encryption security overkill? Absolutely not, say users who have already adopted it or are in the processing of adopting it. One reason is to gain some security control over public telecommunications lines used in wide area networks. "We have a good idea of our internal security, but we also use the public carriers for our worldwide WAN, such as CompuServe [Inc.'s] frame relay and British Telecom [Plc.'s] frame relay, and we [don't control] their level of security," says Richard Perlotto, corporate network security manager for VLSI Technology Inc., in Tempe, Ariz. "Even if you own most of your own equipment, with frame relay you don't own the router, the carrier does. Frequently [the carrier has] modems attached to those routers to manage the equipment remotely," Perlotto adds. Those modems can allow hackers to tap in and grab data as it is being transmitted, without ever being detected by the company's security systems. Consequently, VLSI is currently evaluating encryption boxes and other products that sit on either end of a connection, such as NetFortress from Digital Secured Networks Technology Inc. (DSN), in Englewood Cliffs, N.J. One box encodes all traffic on the fly when it's being transmitted, and the other decodes the information upon receipt. Router vendors offer similar add-ons. Besides simply letting employees sleep better at night with the knowledge that their corporate secrets are safe, encryption technology can mean that a company can operate more efficiently and cost-effectively, users say. "Right now, we drop letters into the post office, which isn't very secure when you think about it," Fresen says. "After all, anyone could look at them. Or we send a courier. But if we can secure our [Lotus Development Corp.] cc:Mail system, there's a tremendous cost savings to us compared to sending a courier to Hong Kong three times a day. And we'll be able to do things in a day that used to take a week." Fresen is currently testing Entrust 2.0 from Northern Telecom Ltd. (NorTel), in Research Triangle Park, N.C., as an encryption add-on to e-mail. GETTING KEYED IN. But before you can go out and purchase an encryption system, you need to do some serious homework. Encryption involves multiple technologies, competing protocols, and complex mathematics. You can start the learning process by understanding the two components that make up most encryption systems: the key and the certificate. The key is the algorithm or mathematical formula that encodes the message itself. It must be sent to the message recipient so the message can be decoded, hence the term key. The size of the key, measured in bits, determines how complex the algorithm is and how tough the code is to crack. The state of the art for encryption technology used exclusively within the United States is 1,024 bits. However, the maximum size key that is allowed to be exported is 40 bits. Keys come in two flavors: symmetrical, or public key model; and asymmetrical, or public key/private key model. A symmetrical key uses the same algorithm to encode and decode a message. This is the technique used by the public key encryption program Pretty Good Privacy (PGP). PGP assumes what security experts call the peer trust model. That is, the sender knows and trusts the receiver and is therefore perfectly comfortable in sending the key on its way. Herein lies the "pretty good" part of the privacy. Although the algorithm itself makes the message difficult to crack, the key exchange is only pretty good when compared with other methods. On the other hand, the great advantage to PGP is that it creates no key management overhead, which is the biggest drawback of asymmetrical keys. In the asymmetrical model, users have a public key stored somewhere that is available. Should someone want to send an encrypted message, the sender locates the public key of the recipient, encodes the message, and sends it off. The receiver then uses a private key to decode the message. The private key is different from the public key, but they are mathematically linked so that the private key is capable of decoding the message. Asymmetrical systems require no trust between the sender and the recipient. That's good. But they do create administration overhead in the form of storing and maintaining public and private keys. Public/private key exchange is the technique used by RSA Data Security Inc., which was recently sold to Security Dynamics Inc., in Bedford, Mass. RSA uses a technology that is actually an adaptation of the decade-old National Institute of Standards and Technology's peer-trust Data Encryption Standard (DES), still used in many products. DES is a method of grabbing random keys for each encryption task, rather than using the same key repeatedly. Cryptographers say that RSA solves some problems, such as the trust issue but generates others. "Say I want to send a secure message. The first thing I do is take a random key and encrypt the message with it," says Paul Kocher, an independent cryptography consultant in Menlo Park, Calif., and one of the people responsible for discovering the flaw in the security of Netscape Communication Corp.'s Netscape Navigator. "But without that key, I won't know how to decode [the message], so I take an RSA public key and encrypt the random DES key with my recipient's public key. The recipient uses a private RSA key to decrypt the DES key. If it sounds convoluted, it is. RSA is very slow and cumbersome. DES is fast and efficient, but it doesn't give you the security of the public/private key system," Kocher explains. RSA remains one of the most well-known encryption technologies, but it is not, by far, the only public/private key exchange method currently in use. For example, other vendors use a competing version called Diffie-Hellman. It is a mathematically different implementation of the asymmetrical model, and it is the method employed by DSN's NetFortress. THE REAL YOU. Using public or public and private keys is the foundation of encryption, but keys can't verify a recipient's identity. "When you're talking about sending secured messages, there are two goals you've got. One is to make sure that the information stays confidential, and the other is that it does not get tampered with," Kocher says. Enter the certificate, also called the digital signature. Certificates act like an electronic driver's license. They authenticate that the receivers and senders are who they say they are. "The issue is trust. When we owned our own 3270 cabling, we trusted it, we worried less. Now I have someone at Daytona Co. that needs access to Chrysler Corp. across multiple networks. What sort of trust do I have?" asks Bob Maskowitz, technical support specialist for Chrysler, in Detroit, and a member of the Internet Architecture Board of the Internet Engineering Task Force (IETF). "I need to authenticate that this person is allowed to update [a document]." Certificates can be created and managed by a third party, such as VeriSign Inc., in Mountain View, Calif., or they can be created and managed internally, with products such as NorTel's Entrust, which also performs encryption. Once a certificate is obtained, it becomes the user's digital signature. When digitally signing something, the recipient of the signature gets all of the information contained on the certificate, such as who the person is, the person's address, or other items chosen to be included on the certificate. The digital signature also says who granted the certificate, when it expires, and what level of verification was done. "There are three classes of certificates," explains Gina Jorasch, director of product marketing for VeriSign. "In Class 1, we check for a unique name, that the e-mail address is correct, and that the person receiving it has authority to access that e-mail account. In Class 2, we check the name, address, driver's license, social security number, and date of birth. For a Class 3 we check all of those things, plus we check against the Equifax [credit reporting bureau] database." Although certificates provide the invaluable service of authenticating users, organizations that care enough about their security to use encryption and certificates may not want to trust an outsider to handle them, according to users. "Do you think Ford [Motor Co.] or Chrysler is going to let someone else control their certificates? Then there is this issue of where did you get your certificate from? Am I going to let you query my database to get a key? No way," Maskowitz says. From a network management perspective, certificates are also an issue. Unless they are outsourced, they will add a significant amount of system management overhead to an encryption system, even with systems such as Entrust that include management features. Most certificates are set to expire in a set amount of time, such as a year. Someone will have to see that they get reissued. Someone will also have to make sure that certificates for employees who leave a company are revoked and that new employee certificates are issued. SMIME'S THE WORD. The final area of concern IS managers face is the new wave of protocols being spewed out by various industry consortiums. Numerous APIs are being created that cover all the aspects of using encryption. Although these APIs are posing as standards, in truth the two most popular APIs for the commercial sector are merely vehicles for the mass adoption of a particular company's key technology. Nevertheless, vendors of products such as e-mail packages are lining up behind them. The four big protocols being worked on are Secure Multipurpose Internet Mail Extensions (SMIME), Multipart Object Security Standard (MOSS), the next-generation version of PGP that allows asymmetrical key exchange, and Message Security Protocol, says Rik Drummond, chairman of the IETF's electronic data interchange over the Internet committee and president of The Drummond Group, a consultancy in Fort Worth, Texas, that helps corporations choose and implement networking and security systems. MOSS is the API for the Department of Defense, and it will be mandatory for anyone in the government or anyone who does business with it. But commercially, SMIME and PGP, Version 3.0, are more robust choices, Drummond says, and they offer features best-suited for the commercial sector, such as backward compatibility, and better key and certificate management capabilities. By far the biggest names in the Internet world have lined up behind SMIME, including Microsoft Corp., which intends to make Microsoft Exchange SMIME-compliant; Netscape; and Qualcomm Inc., maker of the Eudora e-mail package. That makes it a comforting set of protocols to choose because corporations that buy products with SMIME or that purchase SMIME toolkits for customer applications will know that they will be able to communicate with the vast majority of others through a de facto standard. Those using other protocols will be left talking to themselves. Still, SMIME, as it stands now, isn't a panacea. Among its problems is that "the signature is exposed outside the encryption envelope," Maskowitz says. Also, once a message is encrypted with someone else's public key, the sender of the message can't open the message to make changes, Maskowitz adds. The architects of SMIME haven't completed the APIs yet, so there is some possibility that these problems will be fixed but in all likelihood not in time to be included in the first crop of SMIME-compliant applications, due to start rolling out this fall. Even with such serious issues still up in the air, today's encryption and certification products can offer a great deal of protection, especially if the Internet or a wide area intranet is becoming a serious business tool for a particular organization, and it can't wait for a de facto standard to emerge. For those with the time to wait, the learning curve should be ascended now. Mass adoption of encryption technology is a virtual certainty. Those that ignore it will find their secrets being blabbed to the world. -------------------------------- Uses for encryption technology: * Sending sensitive data over publicly owned wide area links; * Sending sensitive data over Internet e-mail; * Electronic commerce; * Electronic data interchange over the Internet; * Order entry/order status over an intranet or the Internet; * Automated access to personnel files; * Storing sensitive data online; * Distribution, newsgroup style, of sensitive data. -------------------------------- Will the export of strong encryption be allowed? One of the problems with adopting encryption worldwide is that the federal government severely restricts its export. In fact, encryption technology is classified as munitions. Therefore, U.S. encryption vendors and corporations are forbidden from exporting and deploying versions that use more than a 40-bit key. However, companies in other countries, such as Japan, can freely sell encryption technology that uses the tougher 1,024-bit standard. The U.S. government isn't completely closing its eyes to the matter. In July, Vice President Al Gore unveiled a proposal that would create a key-escrow system allowing keys greater than 40 bits to be exported but requiring a third party to keep a copy of a key that could be used by law enforcement officials. (See U.S. considers easing encryption export laws.) And this past June, the Senate Subcommittee on Technology, Science, and Space heard a slew of testimony from encryption vendors and other experts on the problem. In fact, there are several bills pending in both houses of Congress that would relax the current export restrictions. The Security and Freedom Through Encryption Act was introduced in the House by Rep. Robert Goodlatte, R-Va. Meanwhile, The Encrypted Communications Privacy Act of 1996 was introduced in the Senate by Sen. Patrick Leahy, D-Vt., and the Promotion of Commerce On-Line in the Digital Era Act of 1996 also sits before the Senate. All three laws would relax the 40-bit restriction on keys as well as eliminate other restrictions on international use and development of encryption. Officials of U.S. corporations look forward to these changes and believe that such changes would improve their ability to compete in the international marketplace. "We're an international company, so we can't use the domestic version of Netscape [Communications Corp.'s Netscape Navigator]. And we can't trust the data using the international versions," says Richard Perlotto, corporate network security manager at VLSI Technology Inc., in Tempe, Ariz. Julie Bort is a free-lance writer based in Dillon, Colo. Please direct your comments to InfoWorld Electric News Editor Dana Gardner. [Image] To respond to this review, go to the forum. [Image] [Image] Copyright © 1996 InfoWorld Publishing Company ------------------------- end silly article -------------------------- --------------------------- begin response --------------------------- -----BEGIN PGP SIGNED MESSAGE----- This references http://www.infoworld.com/cgi-bin/displayStory.pl?960830.crypt.htm Hi, First of all, I'd like to commend InfoWorld for covering a very important topic: cryptography. There are, however, some very significant flaws in the story, which I hope will be corrected soon. As the article exists now, the information is sufficiently incorrect to be more harm than if the article didn't exist at all. Anyone using it as a guide will be only further confused. The quotes are indented two spaces, with my comments below... Although no encryption algorithm is in and of itself crack-proof, several of them are so complex that they are virtually unbreakable. Coupled with proper implementation, authentication, and secure connections, encryption solutions can add a high level of security to any company's arsenal. However, it is an area that requires a knowledgeable person to make the purchasing decision because the technology is very complex, the best product selected will add a level of administration overhead, and numerous industry consortiums are developing competing APIs. Also, there are a lot of people who simply don't know what they're doing when it comes to cryptography and security. Many products claim high degrees of security, but are hardly strong enough to keep someone's kid sister from deciphering the message. The key is the algorithm or mathematical formula that encodes the message itself. It must be sent to the message recipient so the message can be decoded, hence the term key. Bzzzt. The formula is the algorithm. The key is a piece of data (often times, a passphrase, or a relatively small file) that is fed to the algorithm along with the data to be encrypted or decrypted to produce the desired result. The idea being that if an attacker knows what algorithm someone is using, and they have the encrypted message, they'll not be able to break the message unless they can also get their hands on the key. Hence, the key needs to be sufficiently large such that it can't be easily guessed by an attacker trying keys at random (or by effectively starting at "1" and working his way up.) The size of the key, measured in bits, determines how complex the algorithm is and how tough the code is to crack. The state of the art for encryption technology used exclusively within the United States is 1,024 bits. However, the maximum size key that is allowed to be exported is 40 bits. Bzzzt. The complexity of the algorithm and key size are two different matters entirely. The level of complexity, by the way, typically increases the chance for error (in both algorithm design and implementation) more than adding any levels of security. A secure algorithm doesn't have to be complex. However, its key must be of sufficient length to be "computationally infeasable to break." Let's take the example of a bicycle combination lock. It has a chain which will secure the bicycle to a rack; we'll assume that it's some newfangled sort of chain which is resistant to bolt cutters and all of those sorts of things. The security of this lock now rests in the actual locking mechanism. It's a very simple tumbler lock, perhaps having three or four digits between 0 and 9 that collectively make up the combination. The "key" is the combination in this case. The lock is simple, but it can be difficult to break, if the length of the key is long enough. If there is only one digit, there are 10 possible (10**1) keys. An attacker can quickly guess this and have a new bicycle. However, each time a digit is added to the key, it increases the number of combinations an order of magnitude. Two digits will have 100 possible (10**2) keys, three digits will have 1000 (10**3), four will have 10,000 (10**4) possible, etc. The key size necessary to prevent breaking the solution will depend on your attacker. I mentioned the term "computationally infeasable" earlier. The term simply means that more time and money would need to be spent in breaking the key than the value of that which it locks. If a bike combination has 10**8 (100,000,000) possible combinations, and a thief can try 60 combinations per minute, it would take 165 weeks of continuous attempts to try every combination. By that time, enough lawns could be cut to buy two such bikes. Because computers are binary, we work in bases of two, instead of base 10, which the bicycle combination lock uses, but the principle is the same. Each time you add a digit, you increase the number of keys by an order of magnitude (in a binary system, that means you double it, in a base 10 system, you increase it 10 times.) The key size of your algorithm, therefore, must be large enough to prevent an attacker from having any benefit to recovering that which is encrypted. Keys come in two flavors: symmetrical, or public key model; and asymmetrical, or public key/private key model. Symmetric cryptosystems are sometimes known as "conventional." Asymmetric cryptosystems are known as "public key" ciphers. (Public key/private key *is* the public key model, and an asymmetric cipher!) Symmetric ciphers require the same key to encrypt and decrypt. If you imagine the encryption formula on the left side, and decryption on the right, you apply the same key to both sides in order to encrypt or retrieve the plaintext. Hence, the name "symmetric." Systems which use a different key to encrypt from the key to decrypt, therefore, are asymmetrical. The note about key sizes is also misleading: conventional cryptosystems require a much, much smaller key for security than do public key cryptosystems. Because the math is different, a 128 bit key on a conventional algorithm is roughly the same security as a 2304 bit asymmetric cipher key. The "state of the art" in symmetric cryptosystems is about 128 bits. In this type of system, the government does not allow export of keys greater than 40 bits. Using a 1024 bit key in a symmetric cipher would provide an insane level of security, but would also be very, very slow to use. A symmetrical key uses the same algorithm to encode and decode a message. This is the technique used by the public key encryption program Pretty Good Privacy (PGP). This is wrong, I will explain later. PGP assumes what security experts call the peer trust model. That is, the sender knows and trusts the receiver and is therefore perfectly comfortable in sending the key on its way. Herein lies the "pretty good" part of the privacy. Although the algorithm itself makes the message difficult to crack, the key exchange is only pretty good when compared with other methods. VERY WRONG! I'll explain this also later. On the other hand, the great advantage to PGP is that it creates no key management overhead, which is the biggest drawback of asymmetrical keys. Key management is the biggest problem for the keys of symmetric ciphers, not asymetric ciphers. In the asymmetrical model, users have a public key stored somewhere that is available. Should someone want to send an encrypted message, the sender locates the public key of the recipient, encodes the message, and sends it off. The receiver then uses a private key to decode the message. The private key is different from the public key, but they are mathematically linked so that the private key is capable of decoding the message. Entirely correct. Public/private key exchange is the technique used by RSA Data Security Inc., which was recently sold to Security Dynamics Inc., in Bedford, Mass. RSA uses a technology that is actually an adaptation of the decade-old National Institute of Standards and Technology's peer-trust Data Encryption Standard (DES), still used in many products. DES is a method of grabbing random keys for each encryption task, rather than using the same key repeatedly. Cryptographers say that RSA solves some problems, such as the trust issue but generates others. ACK! NO! RSA is an asymmetric cipher. DES is a symmetric cipher. That's the only difference. How keys are managed is entirely dependant on how the system is implemented. Anything can be assigned a key "at random," by allowing a user's passphrase to be the key. Now it seems like a good time to explain the way that PGP (and Netscape's encryption system) works. Asymmetric ciphers, such as RSA, are very slow. Their key management, however, is very nice and flexible, which is why we like to use them. In a system that requires flexible key management, a high level of security, as well as decent performance, both symmetric and asymmetric ciphers are used. If Alice wants to send Bob a message in such a system (like PGP), she simply composes her message, and tells her mailer to PGP-encrypt the message. PGP will find Bob's public key (either from her key ring, or from a database, perhaps, but it doesn't matter.) The message will then be encrypted with a random SYMMETRIC key (in the case of PGP, it will use the 128-bit-key IDEA cipher). That session key, then, will be encrypted using Bob's public key, and both the session key and message will be sent off (in one PGP encrypted message). Bob will see his mail from Alice, and then his PGP will decrypt the session key, and apply it to the encrypted message, yielding the plaintext: Alice's message. So, in PGP, the MESSAGE is encrypted using a random session key (which is symmetric.) The SESSION KEY, then, is encrypted using the recipient's public key. The rest of the article seems to be generally on track, but certificates and signatures have been confused. A certificate is a cryptographically secure message that states the identify of the presenter. In that way, the analogy to a driver's license is correct. A trusted third party issues the certificate. A digital signature, however, is the cryptographic equivalent of signing your name to something. For example, with PGP, I can digitally sign an email message. PGP does this by taking the message, encrypting it with my PRIVATE key, running the result of that through a secure one-way function ("hash"), and attaching the result to the bottom of the message. A user can then verify that the signature is legitimate by applying my PUBLIC key to the message, and running the result back through the hash, and comparing the two. If they match, the signature is good, if not, something is amiss. (PGP, naturally, handles all of this automatically.) Therefore, U.S. encryption vendors and corporations are forbidden from exporting and deploying versions that use more than a 40-bit key. However, companies in other countries, such as Japan, can freely sell encryption technology that uses the tougher 1,024-bit standard. The two are being confused again. See my earlier note about comparable keys. If you have further questions, please feel free to contact me. If there is interest, I would also be willing to write a series on how to choose a cryptosystem. I am very concerned about the state of cryptographic knowledge in the industry. The area is vital for successful companies' IS departments to understand, and understand well. Yet, the general level of knowledge is abysmally low. I applaud efforts by InfoWorld to increase coverage of this important topic, but I emphasize that the material presented must be correct. Many vendors are currently offering solutions they call secure. Without an understanding of how cryptography works, an IS organization is completely unable to choose between that which is good security and that which is snake oil. A "snake oil FAQ" is being drafted, but is not yet available. In the mean time, there are cryptography FAQs available from ftp://rtfm.mit.edu/pub/usenet-by-group/sci.crypt/ - -- C Matthew Curtin MEGASOFT, INC Chief Scientist I speak only for myself. Don't whine to anyone but me about anything I say. Hacker Security Firewall Crypto PGP Privacy Unix Perl Java Internet Intranet cmcurtin@research.megasoft.com http://research.megasoft.com/people/cmcurtin/ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Have you encrypted your data today? iQEVAwUBMireN36R34u/f3zNAQF+BQf/XD0fPYFuOQsd+u2k4zE1UpfZQKaP+SDw RUhx6R7LnD0ZK5dA+seStvsLl+cvg5tu2wMzf9bniS7taj2DHwmu8MDWYwJPnQST Iiti6XBAoFjCJYWaVghHQzVKw8vxlNC20LzyJ791PdabpUo5ztpf+AXVHGAfWaTg F3ZNYWbbyxg81uxAnKMM/Li6NOKJhcE6nNO+eHUMFLciFki+mz/mOT45fUPs0R9y 4UYLQDvcSVAt246xSufwqbrSY/4dUB3A7KjYvbqWUjYRF/40c1h3K6h69dDnOR/8 SY+AZNnZSzQZbMbHNpjlJ+E71Yz+9Ppvgl6Eeo7oqa+PNeYW0W9GMQ== =PS8M -----END PGP SIGNATURE----- ---------------------------- end response ---------------------------- -- C Matthew Curtin MEGASOFT, INC Chief Scientist I speak only for myself. Don't whine to anyone but me about anything I say. Hacker Security Firewall Crypto PGP Privacy Unix Perl Java Internet Intranet cmcurtin@research.megasoft.com http://research.megasoft.com/people/cmcurtin/