Types of Encryption
Symmetric Encryption
With symmetric encryption, the same encryption key is used both to encrypt the plaintext and to decrypt the ciphertext. A secret key is chosen at the time that the plaintext is first encrypted. As long as a person or system has that secret key, the ciphertext can be decrypted back into the original plaintext using the same symmetric encryption algorithm. This approach to encryption is relatively simple, since it typically uses a password or passphrase as the secret key. Symmetric encryption is used for full-disk encryption in LUKS1 and BitLocker,2 by way of example.
Symmetric encryption as a means of communication between two different people or systems has a serious limitation that can lead to loss of confidentiality. Both people (or systems) need to know the secret key in order to decrypt messages received by the other side. Typically, a secret key is created and shared between both parties in a process called a key exchange. The need for a key exchange creates a chicken-and-egg problem with the encrypted communication, since the encryption cannot happen until the key has been exchanged, but secure exchange of the key over any type of network requires encrypted communication for confidentiality. If the key is sent in plaintext as part of the communications, an adversary can simply intercept the key and decrypt the communications.
While pre-sharing a key in person is possible under certain circumstances, it isn’t practical in the general case of Internet communications. One way that keys are sometimes shared over a network is to use a side channel, or a second network link or means of communication. For example, when establishing an encrypted link between two systems, the system administrators might share the key by some seemingly unrelated side channel, like a text message between them. However, text messages are not generally encrypted, so an adversary who is able to determine that the sharing is taking place over the side channel can simply monitor the side channel to intercept the key. Intercepting confidential information like an encryption key via a side channel is called a side-channel attack.
Even when a symmetric key can be shared securely, there is still a vulnerability if the key is weak, meaning that it is easy to guess or brute-force the key and thereby decrypt the data. We’ll take another look at this problem in a future lesson.
Public Key Encryption
One solution to the key exchange problem is to use public key cryptography when sending messages. Instead of using a single shared key, the cryptographic system is constructed in such a way that each entity (person or system) has two keys: a public key and a private key. The public key is shared freely and does not have to be protected. However, each entity must protect its private key to maintain the privacy of the encrypted communications. Public key cryptography is used in systems like Transport Layer Security (TLS)3 and Pretty Good Privacy.4
To send a message from one entity to another using public key cryptography, the sender uses its private key to encrypt a message to the recipient’s public key. The keys are designed so that the recipient can verify that the message actually came from the sender and not some other party, since the message is signed in a way that can be verified with the sender’s public key. Since the message is encrypted only for the recipient, only the recipient can decrypt the message using the recipient’s private key.
A potential weakness in public key cryptography is that there needs to be a way to verify that a public key actually belongs to the legitimate person or company using it. In the case of TLS, a public key is embedded into a certificate, which provides metadata about the public key (such as the geographic location of the server) and a place for the public key to be signed by a Certificate Authority (CA). A CA uses some kind of business process to ensure that public keys legitimately belong to an entity or person. Only once this process is satisfied is the entity’s public key signed by the CA. Software that is configured to trust the CA can then check to see if the CA has endorsed the public key, only trusting that the public key is valid if a trusted CA has endorsed it. CA Certificates, which provide the public keys of the certificate authorities themselves, are normally shipped with software that makes use of TLS, such as web browsers.5 This system is known as a Public Key Infrastructure (PKI) and is defined by the X.509 standard.6 It is used for browser TLS connections to secure websites on the Internet.
One risk with PKI is that CAs can themselves become targets for attackers. If an attacker can compromise a CA, then the threat actor can issue fraudulent certificates that cause software applications to trust malicious public keys.7 The alternative to a centralized PKI is to use a decentralized way to share and authenticate public keys. Pretty Good Privacy (PGP) uses such a centralized system, known as a Web of Trust. In a Web of Trust, users of encryption who know one another will sign each other’s public keys, thereby declaring that a public key does, indeed, belong to a specific other person. As these people meet other people, they also exchange and sign each others’ public keys, eventually creating a decentralized web of key signatures. Mathematical algorithms are used to evaluate the number of signatures that a key has received in order to make a decision about whether or not to trust that key.8
Notes and References
-
BitLocker Drive Encryption. Microsoft Support. ↩
-
The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446. August 2018. ↩
-
OpenPGP Message Format. RFC 4880. November 2007. ↩
-
Included Certificates. Mozilla Wiki. May 22, 2023. ↩
-
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 5280. May 2008. ↩
-
Paul Turner, William Polk, and Elaine B. Barker. Preparing for and Responding to CA Compromise and Fraudulent Certificate Issuance. ITL Bulletin, National Institute of Standards and Technology. Gaithersburg, MD: July 10, 2012. ↩
-
Konstantin Ryabitsev. “PGP Web of Trust: Core Concepts Behind Trusted Communication.” Linux.com. February 7, 2014 ↩