Everyone has been to a webpage where the page is secured using some sort of SSL encryption and the beginning of the URL has https instead of http. Most people have a basic idea of how it works and that the data you enter in a form is encrypted when sent to the server (e.g. Your credit card information). But how can the server decrypt this encrypted information if we can’t just blatantly send the encryption key to server with the risk of an intruder stealing the key and then decrypting our information? This is the problem that began the study of public key cryptography.
Public key cryptography is the exchange of a secret key from one party to another through public transactions when the secret key isn’t exchanged. So how does it work? Say we have two people, Bob and Sally, and Bob would like to send Sally a secret box that is protected by a combination lock. If Bob sends the box to Sally with his lock on it, he will have to send Sally the combination along with the box. Anyone can read the combination and unlock the box before Sally even receives the box. This will not work. But what if Sally sends Bob her lock, Bob locks the box and sends Sally the box with her lock on it. This would work and be secure because Bob does not know the combination to her lock and once he locks the box, he can not open it. Sally is the only one who knows combination and she will safely receive her box.
So how does this work when entering your credit card information on a webpage and clicking “Buy Now”? What is the algorithm behind all of this? Well SSL uses an algorithm called Diffie Hellman Key Exchange. This algorithm works as the following.
Say we have a client and a server trying to decide on an encryption key. The client and the server share two public values p and i. The value p is a prime number, only divisible by itself and one, that is a large number greater then 1000 and the value i is an integer that is less than p. The client and the server generate a private value r that is a large number greater then 1000 and is secret to only itself. Now the server will generate a key value a using the formula a = (i^r) mod p where mod is represented as modulus division. The server will send the value a to the client where the client will use the same formula to calculate its encryption key k. k = (a^r) mod p Now the client will do the same thing by calculating the key a using a = (i^r) mod p with its values and sending the a value to the server where the server uses the a value to calculate the encryption key using the formula k = (a^r) mod p . The value of k for both the server and the client will be the same. What the best part is is that it is almost impossible to generate the encryption key value k from using all of the public transfered values.
Here is an example (p and r and small values for simplicity but it reality, they are greater than 1000):
|p = 13||p = 13|
|i = 6||i = 6|
|r = 3 (Not shared)||r = 10 (Not shared)|
|a = 6^3 mod 13 = 8||a = 6^10 mod 13 = 4|
|k = 4^3 mod 13 = 12||k = 8^10 mod 13 = 12|
|Encryption Key = 12||Encryption Key = 12|
As you can see, the values that the server and client send back and forth do not represent the actual encryption key in anyway. When p and r are large values, it is almost impossible for any intruder to reverse the calculation and obtain the encryption key. This is a magic behind any type of SSL encryption.
Follow me on twitter @ShawnJanas