Our cryptographic keys are often the only unknown variable when protecting data or creating digital signatures. In this video, you’ll learn about key strength, key exchange, and how to protect different sessions with dynamic keys.
<< Previous Video: Hashing and Digital Signatures Next: Steganography >>
Cryptography is an interesting science because it allows us to protect data, but the process that we use to protect the data is well known by everyone. The algorithms that we use, the processes that we use, to be able to take plaintext, convert it into ciphertext, and then back to plaintext, is a process that is open and available for anyone to view.
The one variable that people don’t know, is the encryption key. And it’s that single encryption key that allows us to encrypt data, to hash information, and to provide a digital signature. That’s why it’s so important to keep your private key private and to make sure that no one else can gain access to that very valuable key.
In the world of encryption keys, a larger key tends to be more secure. That’s because if you want to brute-force a particular key, you would have to run through every combination to see if you can determine what that original key happened to be. And if it’s a longer key, then it takes a much longer amount of time to perform the brute force.
For symmetric encryption, we tend to see keys that are about 128-bits or larger, and of course, as our computing capabilities increase, we tend to increase the size of our keys so that we make it harder and harder for someone to brute-force.
Asymmetric keys tend to be much larger than symmetric keys. These are keys that are using very large prime numbers to perform these calculations. And asymmetric keys tend to be 3,072 bits 4,096 bits or even larger.
One of the logistical challenges we have is the need to be able to share keys between two people so that you can then perform an encryption. The challenge though, is how do you transfer a key to someone, over a medium that is inherently insecure? There needs to be some way to be able to share encryption keys, without having someone else be able to see us sharing those encryption keys.
One way to do this is an out-of-band exchange. This is one where you might want to call someone on the telephone or use a carrier to send that key from one person to another. It’s out-of-band because you are transferring this key outside of the network.
Of course, it’s much more convenient if you’re able to transfer this key directly across the network and have it appear instantly on the other side. We often do this by protecting this key, by using an additional encryption method. For example, it’s very common to use asymmetric encryption to be able to send a symmetric key to someone else.
Here’s one way to provide this very fast ability to exchange keys without sending the key in the clear across the network. You could use asymmetric encryption to be able to encrypt the symmetric key inside of it. The client would take this symmetric key, which would be the plaintext, and would encrypt it using a server’s public key to create the ciphertext.
That ciphertext is then sent to the server. The server is able to decrypt that ciphertext using its private key, which would allow it access to the session or symmetric key that we originally started with. This means that we can transfer this symmetric key across the network in an encrypted form that uses asymmetric encryption, to transfer a symmetric key.
If you’re using the symmetric key as a temporary session key, then it needs to be changed often. As the name implies, a session key tends to be used for an individual session, and once that session is over, the keys are no longer used.
We refer to this key type as an ephemeral key because it’s a key that’s not permanent. It’s also important that these session keys are unpredictable because we’re using these as encryption keys for our session, and we want to be sure that no one else is able to predict the type of key that we might use.
Another way to share a symmetric key between two devices without sending that symmetric key over the network is with something like Diffie-Hellman key exchange. With Diffie-Hellman key exchange, you would have a private key for each user. For example, Bob has his private key, and Alice has her private key.
You would then use the public key of the other side. For example, Bob would use Alice’s public key, and Alice would use Bob’s public key, and both sides would combine both of those together, to create a symmetric key. And when you do that, on each side the symmetric key turns out to be identical. This means that both Bob and Alice could calculate a symmetric key on both sides, and use exactly the same key without ever having sent that key to each other.
But if your public and private key never change, this could create a vulnerability, especially if someone has access to the raw data going across the network, and they somehow gain access to your private key. Take, for example, web servers, which commonly use encryption keys for TLS or what used to be called SSL, and they’re based on a web server’s key pair.
So web server has a public key, and a private key, that’s used for this asymmetric process. It’s this asymmetric key pair that is then used to encrypt all of the symmetric keys that are used to communicate back and forth to this website server. This means if you somehow gain access to the server’s private key, and you capture the information going across the network, you can decrypt that information, to see what’s on the inside.
For many websites, this provides a single point of failure for all of the encryption. So there needs to be some other way to provide encryption to the server that would prevent somebody from being able to decrypt it after the fact.
To work around this problem, many web servers have implemented Perfect Forward Secrecy or PFS. This changes the encryption process so that you’re not using the same private key every time, to be able to transfer that symmetric key across the network.
This uses an algorithm called elliptic curve or Diffie-Hellman ephemeral. In fact, this is a certificate that shows that it’s using ECDHE and that is Elliptic Curve Diffie Hellman Ephemeral. These keys are created just to transfer a single session, and then once that session is over, those keys are no longer used. This means that every session will have a different set of encryption keys, which means we can’t go back after the fact and decrypt all of that network traffic, based on a single server private key.
Since we’re creating these public and private key pairs on the fly for every session, there is some additional overhead required to be able to perform this function. And not all servers are going to have the bandwidth or capabilities in their hardware, to be able to perform Perfect Forward Secrecy.
We also have to make sure that the browser is communicating to this website server can support PFS, and most modern browsers do. You’ll have to look at the individual browsers to make sure that those browsers can support the same encryption method that you’re using on the webserver.