Symmetric and Asymmetric Cryptography SY0-601 CompTIA Security+
Let's begin our conversation of the differences between symmetric encryption and asymmetric
encryption, by focusing first on symmetric encryption. This is encryption where you use a single key to
encrypt the data, and when you want to decrypt the data, you use exactly the same key to decrypt it.
This means that if this key does become available for others to see, that you'll have to completely redo
all of your encryption because now everyone has a copy of the key that can be used to decrypt this data.
You'll sometimes hear symmetric encryption referred to as a secret-key algorithm or a shared secret.
That's because that single key is the secret that everyone needs to know, to be able to decrypt the
information. One of the challenges you have with symmetric encryption is it's difficult to scale. How do
you share a key with others, when you don't currently have a way to encrypt that information. You can
think of this as somebody carrying the key in a locked case, they're protecting the key until they get to
their destination, and only then can they share that key with another person. But across the network,
you don't have a locked case. And since you don't have a key that both sides can share, you don't have a
way to encrypt the key, to be able to send it to the other side. This means we have to find other ways to
be able to share this key so that we can use symmetric encryption. One way to get around this problem
of scalability is to use asymmetric encryption. The problem, though, is that asymmetric encryption
requires more overhead and more work by the CPU. Symmetric encryption requires relatively fewer
resources than asymmetric encryption. Often, you'll see the two combine, where you'll use asymmetric
encryption in order to transfer a symmetric key to someone else. So very often those two algorithm
types are used in conjunction with each other. Unlike symmetric encryption, where there is a single key,
with asymmetric encryption, there are multiple keys. You'll sometimes hear this referred to as publickey cryptography, because, there is a public key and a private key. In some situations, there can even be
more than two keys, but for the examples that will give today, we'll deal with the two keys, a public key,
and the private key. The private key as the name implies, is the key that only you have access to. It is a
private key because nobody else knows what that key is. There is another key that is mathematically
related to the private key called the public key. This is the key that you give to everybody. You can post
the public key on a public key server, you can hand it out to people in email messages, you can put it on
your website, and everyone who wants to be able to encrypt information and send it to you needs to
have your public key. Once somebody encrypts data with that public key, the only way to decrypt that
information is by using the corresponding private key, and of course, that's the key that only you have
access to. Interestingly enough, you can also do this the opposite way. You can encrypt information with
your private key, and the only people that would be able to decrypt it, are the people that have the
public key. This is the process that we would use for doing something like, a digital signature, for
example. So although we've named these keys public and private, they're really only named that way,
because that's how we're using them. The two keys are mathematically related and depending on which
one you choose when you create the keys, is the one that becomes the private key, and the one that
becomes the public key. Although these two keys are mathematically related, you still can't derive one
key from the other. If everyone has access to the public key, they still would not be able to determine
Internal Use - Confidential
what the private keys should be, even though they have full access to every part of the public key. It's
this interesting relationship between the public and the private key, that enables us to use the
encryption that we have today on the internet. To better understand this relationship between the
public and the private key, let's go back to when we originally create this key pair when using
asymmetric cryptography. We would build both of these keys at the same time. We have a large random
number, there's a key generation program, that is input, and the output to that program, creates the
two keys, the public key, and the private key. By running this key generation program, which uses large
random numbers, and prime numbers as input, it runs it through a generation program, and it outputs
two separate keys. Of those two keys, we choose one of them to be the public key, and one of them to
be the private key, and then we share the public key with everybody, and we keep the private key
private to us. Let's look at the process that's involved in encrypting and decrypting information using
asymmetric cryptography. Let's take a scenario, where Bob and Alice are communicating to each other,
and Bob would like to send some information to Alice that is encrypted. Bob will need a way to create
this encrypted message, like a laptop. He'll need the original plain text. This plain text says, Hello Alice,
and then he'll need Alice's public key. To obtain this key, Bob can ask Alice for her public key, he can
retrieve her public key from a public key server, or he can visit Alice's home page or anywhere else Alice
may have posted the key and download the key from there. Bob then combines the plaintext, with
Alice's public key, to create the ciphertext. Once the ciphertext has been created, the only way to obtain
the original plaintext is to decrypt it with the private key. You cannot use the public key to somehow
undo the encryption process that you've already done. This means that Alice will receive the ciphertext
message, and will apply her private key, to be able to decrypt that ciphertext, and once that's decrypted,
she'll be able to see the plain text that says, Hello Alice. This is the process that occurs every time
someone wants to send information using asymmetric encryption. If we wanted to reverse this process
and have Alice send encrypted information to Bob, she would need Bob's public key, she would encrypt
the data, send that ciphertext to Bob, and Bob would use his private key, to decrypt that ciphertext. We
spoke earlier of the difficulties in being able to scale asymmetric key, because there's no easy way to
transmit that symmetric key across the network, without first encrypting it. And since you haven't sent
the key across the network, there's no way to have a known key on both sides, that you can use for the
encryption process. One way to get around this problem is to use asymmetric encryption, in order to
create a symmetric key on both sides, without having to send that symmetric key across the network. To
be able to do that, you use public and private keys on both sides. Let's take the example again of Bob
and Alice. We know that Bob and Alice use asymmetric encryption, which means, that Bob has a private
key, and Alice has a private key, and of course those private keys are only known to their owners. You
can combine your private key, with someone else's public key, to create a symmetric key. And if you use
the related public and private keys on both sides, you end up with a symmetric key that's identical to
each other. So even though Bob's private key and Alice's public key created the symmetric key, it's
exactly the same symmetric key, if you combine Alice's private key and Bob's public key. By doing this,
the same symmetric key can be created on both sides of the conversation, without ever having to send
the symmetric key across the network. In fact, this is the process used for Diffie-Hellman key exchange,
and it's a key exchange process that's used extensively every day. Hopefully, you're starting to see that
asymmetric encryption, can provide us with functionality that symmetric encryption simply can't do. But
there are some drawbacks to using asymmetric encryption. We're using very large integers of very large
prime factor numbers, and that calculation requires CPU overhead and resources on a machine, to be
able to encrypt and decrypt that information. Of course, we have mobile devices, and internet of things
Internal Use - Confidential
devices, that may not have the computing power that our local workstations have, but they still need to
be able to encrypt and decrypt information. For those, we would use, Elliptic-Curve Cryptography, or
ECC. Instead of using these very large prime numbers, we'll use curves, to be able to create, the
asymmetric keys that we would use for public and private key encryption and decryption. ECC can use
smaller keys, to maintain the same security as non-ECC algorithms, and they require, a smaller amount
of storage and a smaller amount of data that would need to be transmitted across the network. This
allows us to have access to the powerful features available with asymmetric encryption, while we're
using our mobile devices and IoT devices.
Internal Use - Confidential