In symmetric cryptosystems, such as RC4, communicating parties use the same shared secret key to both encrypt and decrypt the communication. For example, if Alice wants to send a private message to Bob, she would encrypt the message with a key (let's call it KAB) and then send the encrypted message to Bob. When Bob receives it, he would need to decrypt the message using the same algorithm (RC4) and the same key (KAB). The obvious disadvantage to this approach is that Alice and Bob must both already know KAB. In addition, a unique key is required for every pair of users that want to communicate. Key management issues quickly become intimidating for symmetric cryptosystems.
RC4 is also known to have several significant flaws in the way it constructs and uses keys. Therefore, most security professionals recommend using alternative symmetric algorithms. Two of the most commonly used ones are the Triple Data Encryption Standard (3DES) and the Advanced Encryption Standard (AES). Many programs that support RC4 also provide built-in support for 3DES and/or AES.
The alternative approach to symmetric encryption is public key (or asymmetric) cryptography, which assigns each user a pair of keys. Every individual has his or her own private key and his or her own public key. These keys are mathematically related in such a fashion that a message encrypted with one key of the pair can only be decrypted with the other key from the same pair. Returning to our example of Alice and Bob, Alice would encrypt the message with Bob's public key and then Bob would decrypt it using his own private key. The nature of asymmetric cryptography makes it possible for each user to freely share his or her public key with other users. The security of the system relies upon the secrecy of the private key. What's the catch? Asymmetric cryptography is generally much slower than symmetric cryptography.
This was first published in May 2007