[Published the first week of July, 2001, at http://searchsecurity.com.]
This month’s column is a bit different. On May 31, 2001, I gave a searchSecurity.com web-based presentation entitled “Introduction to Public Key Cryptography (look for it at http://searchsecurity.techtarget.com/onlineEvents/). There were more questions than there was time to answer them. I’ve selected a few to address this month.
When the press talks about “cracking” or “breaking” an encryption algorithm. They always seem to mean this: the “attacker” decrypted a message by guessing the secret key that was used for the encryption. This is not breaking or cracking a particular algorithm. But it does demonstrate the importance of key size. The key size — the number of bits used to store the key, which is an integer number — determines the size of the key space, the number of possible keys that can be used. If you knew that to decrypt a message you needed to guess a number between 1 and 10, would you feel challenged? How about between 1 and 1000? How about 1 and 1^38 (1 followed by 38 zeros). That is (roughly) the key space using a 128-bit key. For comparison purposes, let’s use a (so far) non-existent computer that can guess 1 trillion (1 followed by 12 zeroes) keys a second. On average, it would take around 2 million million million (2 followed by 18 zeroes) years to guess the key.
Not that I can find. But this brings us to the other way someone can “break” crypto. They can break it if the algorithm is faulty (which is why making the algorithm public, available, and subject to examination is so important), or the implementation of the algorithm is flawed. This has, for example, happened with the SSL implementation in Netscape Communicator in the past.
It would be an incredible breakthrough. It would be too good to be true. And it probably is. It sounds like “marketing speak” to me. I can find no such report.
Not just public key crypto, but secret key as well. Such systems will always be targets for attack. But the formula is much more complicated. You have to first look at the key size and algorithm so that you know how vulnerable it is to an attack. 128-bit AES looks pretty good so far. Then you have to combine that with how likely it is someone will target you or your company. Are you securing military secrets or e-mails to your aunt in Minneapolis? It makes a difference. And 2 million-million-million years, or half of that or a tenth of that or even a millionth of that is still a long time.
Algorithms are written to support a certain key size. Also, the larger the key the longer the encryption or decryption will take. You don’t want to use crypto that takes an hour to encrypt your e-mail before you send it. That’s one example of what crypto-mathematicians have to deal with and get right.
If you mean the contents of your e-mail, it certainly should be, assuming a strong enough key-size. The address fields are not encrypted, and therefore not confidential.
Which ever you can afford, where cost is measured in the price of the solution and the people and training required to get it to work. There really is no difference in the security provided.
This is an example of the sorts of trouble we can get into with these systems. A good PKI automates this sort of thing so that as keys are changed, certificates get updated. In this particular case, there is not much you can do except get a new certificate.
Yes, the receiver has to use the same underlying protocols. One can secure e-mail with the popular S/MIME and PGP protocols, the less popular but older MOSS and PEM, or proprietary implementations, such as ZixMail or A-Lock. You do need to have the same type of encryption supported on both or all platforms. So, for example, e-mail encrypted with PGP will work where there is PGP. It doesn’t matter what the Mail User Agent is (Outlook, Eudora, etc.), nor does it matter the platform (Linux, Unix, Windows, Mac, Palm). And there are products that will work across these platforms. Certainly, PGP is the most famous and, perhaps, popular.
##