Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!


	C O L U M N S

Matching Crypto Strength December 27, 1999 By ROBERT MOSKOWITZ Today's security systems are very complex compared to what we started with 20 years or so ago. Perhaps you know someone who remembers entering the DES key into the IBM system that encrypted the payroll data before transmitting it to the bank. Now, systems use a selection of symmetric and asymmetric cryptographic algorithms, hash functions and policy-rule databases in concert to provide the advanced protection required in this age of sophisticated opponents. These interlinked systems must be balanced and properly installed and configured, or any security effort may be for naught. Mismatched security components behave like mismatched electronics: After spending a lot of time and money, all you get is fancy noise. The most common error when building security systems is mismatching the cryptographic strengths of the various subsystems. Good symmetric key algorithms are compared based on key length. DES has a 56-bit key; 3DES has a 168-bit key. Describing the strength of an asymmetric-keyed algorithm is not as simple. RSA and DSA are similar enough that a 1,024 key for each is compatible, but how does elliptic curve (an asymmetric cipher 1/10th the length of RSA) compare, and how do any of these relate to symmetric-keyed algorithms? Yes, it is confusing and few experts can give a straight answer. The best you get are approximate "conservative strengths." Thankfully, these numbers can be used to match strengths. For example, a 1,024-bit RSA key is supposedly weaker than 3DES, so RSA 1,024 is a weak link when used to protect a 3DES key. Configuring the crypto-strength of a security system just right means setting a lot of dials or component choices and their parameter settings. Crypto-strength is controlled by the selection of the symmetric and asymmetric cryptographic algorithms, the hash functions and the MACs (Message Authentication Codes). The strength of a security system is defined as the strength of the weakest security component, so each dial setting must be checked and double-checked. Time is a factor in setting many of these dials. We know that DES can be cracked for an investment of $50,000 and 22 hours of work. We are also warned that a 1,024-bit RSA key will be broken in 10 to 15 years (512-bit keys fell this year). But in the end, the impact of a system's weakness is determined by what you're protecting. A stock trade has a considerably different time line and value than an electronic signature. Today, it is acceptable to protect a DES or 3DES session key for a stock trade with a 1,024-bit RSA key. However, the digital signature on a will should not trust a 1,024-bit RSA key, but instead use at least a 2,048-bit key. The most important element is to realize that each security environment requires its own security settings to work safely and properly. Getting it all right and keeping it current to the most recent advancements in the security and hacking communities is a lot to expect from most security support people. The current confusing array of dials on security systems too often leaves the customer vulnerable because, inevitably, something will be set improperly and result in security discord. Security management is looking for one dial with settings--such as secure e-mail for five years, protect financial data for one day, authenticate medical records for 50 years and so on. This is where good system design and informed product selection come into play. Guidelines for matched security systems should be nothing more than the nature of the information protected, its monetary value and the desired protection interval. The security community must develop a set of scenarios defining preferred detailed settings so that vendors can build user interfaces, describe what is being protected and configure the system accordingly. Robert Moskowitz is a senior technical director at ICSA. Send your comments on this column to him at rgm@htt-consult.com.

Video