Symmetric Encryption
Symmetric encryption
is best described graphically, as shown in Figure below

1
The original message shown in Figure 6.1 is referred to as being in
cleartext
because it's readable. When this original message is combined with the secret key the result is the encrypted message (referred to as ciphertext ). The message can only be decrypted by someone who holds the same secret key. When the process is reversed, the encrypted message together with the secret key will produce the original cleartext message.
The process is relatively simple and very quick, but it has some drawbacks; the most basic is that the same key used to encrypt is also used to decrypt. The secret key must be created and then securely delivered to the person with whom you want to share encrypted messages. The safest way is to put it on a floppy disk and physically carry it to the person, but it is not always possible to do so. It's not secure to send this key via e-mail, because anyone could intercept it and read all of your encrypted messages. Even if you're able to physically get the key to the person, it is good security practice to change the key on a regular basis. When you're exchanging messages with one person, this is not a big deal-but with multiple people, it would be a daunting task. With symmetric encryption you should have a separate key for each person with whom you want to share encrypted information. If you used the same key for everyone, then everyone would be able to read all the messages sent. So you need to generate one key for every person with whom you wish to encrypt. As the number of keys grows, key management becomes an issue.
We're not saying that symmetric encryption doesn't have a place in a
VPN. However, you'll have to address the problem of key management. This leads us to asymmetric encryption.
Asymmetric Encryption
Asymmetric encryption
uses two keys for encrypting/decrypting data. This is
also referred to as public/private key encryption. Figure below depicts asymmetric encryption.

2
The public/private key pair is generated by the person who wants to
encrypt. The private key is secured by the generator of the keys, and the public key is handed out freely to whoever wants to share encrypted information with the generator of the keys (the Pretty Good Privacy [PGP] program originally worked this way). The person who wishes to encrypt a message gets a copy of the public key and encrypts the message with it. Only the holder of the private key will be able to decrypt the message.
The public key is mathematically related to the private key; it is impossible to reverse-engineer the public key to get the value of the private key. For more details about the mathematics involved in encryption, see Applied Cryptography by Bruce Schneier (John Wiley & Sons, 1995).
As is true for symmetric encryption, the keys should be regenerated on a regular basis or any time you think they have been compromised. Although asymmetric encryption reduces number of keys that must be managed, as an encryption process it is 1,000 times slower than symmetric encryption. What we need is a methodology that combines the assets of asymmetric and symmetric encryption. That's where the Diffie-Hellman key exchange method comes into play.
Diffie-Hellman Key Exchange Mechanism
The
Diffie-Hellman
key exchange uses the public/private key pair to generate
a secret key. This process is illustrated in Figure below.

3
In step 1, users exchange public keys. When you're using asymmetric
encryption, the exchange of public keys is all that is required to begin encrypting. But Diffie-Hellman combines asymmetric and symmetric processes.
Each user's private key is combined with their encrypting partners'
public key using the Diffie-Hellman key calculation, as shown in step 2. As we stated earlier, the public and private keys that each user creates are mathematically related; that's how the users can exchange keys, apply the Diffie- Hellman key calculation, and both end up (in step 3) with mathematically identical keys.
Different mathematical groups can be used to generate the identical keys. The Diffie-Hellman standard supports three groups: DH groups 1, 2, and 5. The larger the group number, the larger the prime number used to generate the key pair. The larger groups are more secure but require more CPU cycles to generate the keys. Check Point also gives you the ability to expand the database of groups by adding custom groups.
The process depicted in Figure above solves two problems. First, you have generated the secret key necessary to perform symmetric encryption without having to physically exchange the secret key with your encrypting partner.
Second, you can use that key to symmetrically encrypt data much more
quickly than you can using asymmetric encryption alone. The best aspects of both encryption techniques are combined to yield a process that's better than each individual technique.The encryption processes we've described fill out the P in PAIN, but they are useless unless you get the correct key from your encrypting partner. The next section addresses how to verify that the key is from the correct source and explains the AIN in PAIN.