Asymmetric Key Algorithms
| Asymmetric algorithms, often called public-key algorithms, perform encryption and decryption in a completely different way than symmetric algorithms. Asymmetric algorithms do not rely on a randomly generated shared encryption key that changes per session; instead, they create two static keys. These static keys are completely different but mathematically bound to each other; what one key encrypts, the other key can decrypt. One key alone cannot encrypt and decrypt the same data. We use this encryption method by keeping one key private and giving the other key to anyone in the public Internet. It doesn't matter who has our public key; it is useless without the private key. For example, say Peer X generates a public/private key pair and encrypts a message with his private key. Peer X then sends the ciphertext to peer Y. Peer Y obtains Peer X's public key via some mechanism and can then decrypt the message sent from Peer X. You are probably thinking that anyone who sniffs the wire and obtains Peer X's public key (after all, it is made publicly available) can then read the message, and you would be correct. However, think about this in reverse. Assume peer Y obtains peer X's public key and encrypts a message with it. He then sends this encrypted message to peer X. No matter how many people receive this ciphertext , only one person in the universe can decrypt the message and that is the owner of the corresponding private key. The problem with asymmetric algorithms is the fact that they are very slow, orders of magnitude slower than symmetric algorithms. They are so slow because they use very heavy mathematics to perform their functions. We would never encrypt our bulk data with asymmetric algorithms, but we can still use them to encrypt and decrypt small amounts of data, such as a hash value. More on this topic in the section "Digital Signatures." RSAThe RSA asymmetric algorithm was developed in 1977 by Ronald Rivest, Adi Shamir, and Leonard Adleman. From what math we know today, it is difficult for anyone to attempt to obtain the private key d from the public key ( n, e ). If someone could factor n into p and q , then one could obtain the private key d . This step is a difficult thing to attempt to do, which is what the security of the RSA algorithm is based on. A typical key size for RSA is 1024 bits. The RSA algorithm is used in IPSec for two discreet purposes:
DSAThe Digital Signature Standard (DSA), created by the NIST in 1994, specifies DSA as the algorithm for digital signatures. DSA mainly appears in government installations and was created to work specifically with the SHA-1 hash algorithm. DSA is for digital signatures only. It is not used for encryption, as is RSA. DSA is roughly the same speed as RSA when creating signatures but 10 to 40 times slower when verifying signatures. Because verification happens more frequently than creation, this issue is worth noting when deploying DSA in any environment. D-HThe D-H asymmetric algorithm was created in 1976 by Whitfield Diffie and Martin Hellman. DH isn't used for encryption or digital signatures; instead, it is used to obtain a shared secret "key agreement" between two parties over an insecure medium such as the Internet. It works by sending large mathematical numbers over the Internet; no one on the Internet, even though they can "see" the numbers crossing , can mathematically obtain the shared secret key. Only the two ends of the exchange using the D-H algorithm can compute the shared secret key. The math for the algorithm is as follows : Suppose Alice and Bob want to agree on a shared secret key using the D-H key agreement protocol. They proceed as follows: First, Alice generates a random private value a and Bob generates a random private value b . Both a and b are drawn from the set of integers {1, ..., p -2} . Then they derive their public values using parameters p and g and their private values. Alice's public value is g a mod p and Bob's public value is g b mod p . They then exchange their public values. Finally, Alice computes g ab = ( g b ) a mod p , and Bob computes g ba = ( g a ) b mod p . Since g ab = g ba = k , Alice and Bob now have a shared secret key k . The D-H key exchange is vulnerable to a man-in-the-middle attack. You can rectify the problem by allowing the two parties to authenticate themselves to each other with a shared secret key, digital signatures, or public-key certificates. When two systems need to create a shared secret key between them, they use the services of D-H to obtain it. Many services need shared secret keys: our confidentiality services require one each, our authentication checks require one, and our HMACs require one. The problem IPSec has is that DH is computationally expensive. Too many CPU cycles will be used to create all the shared secret keys we need. Therefore, to reduce the number of D-H exchanges, IPSec will perform D-H a single time and create a number of shared keys derived from the original. These derived keys will be identical on both sides and tagged such that all the possible mechanisms that need a shared key will have one. D-H defines a few modes of operation; the two most commonly used in the Cisco implementation are called D-H group 1, D-H group 2, and D-H group 5. D-H group 1 identifies a 768-bit key, D-H group 2 identifies a 1024-bit key, and D-H group 5 identifies a 1536-bit key. D-H group 1 is faster to execute but is less secure, and D-H group 2 is more secure but slower to execute. D-H group 5 provides for higher security than both D-H group 1 and D-H group 2.
|
