Use Cases for Asymmetric Encryption

Currently, encryption technologies are mainly divided into two types: symmetric encryption and asymmetric encryption. This article uses the openssl command and real examples to explain how asymmetric keys are used in secure communication and digital signatures.

Symmetric encryption is easy to understand. The same key is used for both encryption and decryption. For example, the Caesar Cipher is one of the oldest symmetric encryption algorithms:

We communicate with English letters, but each letter is moved 3 positions forward. In this way, the plaintext is somewhat hidden.

For example, hello becomes khoor after encryption. Here, hello is the plaintext, khoor is the ciphertext, and the key is 3.

The old Caesar Cipher is easy to crack. Modern symmetric encryption algorithms like AES and DES are much more secure and complex, but they still require both the sender and receiver to share the same secret key.

But sharing a secret key comes with a big problem:

If the channel is not secure, we cannot safely send both the ciphertext and the key to the receiver.

The sender needs to send both the ciphertext and the key to the receiver to allow decryption. On an unsafe channel, an attacker can get both the ciphertext and the key, making the encryption useless.

Asymmetric encryption solves this problem.

Asymmetric Encryption

The main idea of asymmetric encryption is to use different keys for encryption and decryption.

An example in real life:

Symmetric encryption is like a safe with a combination lock—the lock and code are one. If the sender ships the safe, he must also send the code, which is not secure if the channel is unsafe.

Asymmetric encryption is like a safe with a lock and a key. The receiver makes both a lock and a matching key, then sends only the lock to the sender. The sender locks the box and mails it back.

Since the key always remains with the receiver, only they can open the safe and get the information.

An asymmetric encryption algorithm generates a key pair—a public key and a private key.

The public key can be published anywhere, but the private key must be kept secret. Anyone on the Internet can use the public key to encrypt data, but only the person with the private key can decrypt it.

Besides encryption, another important use of asymmetric keys is in digital signatures. The private key can sign data and the public key can verify the signature.

If the private key owner wants to publish a statement, he can sign it with his private key and publish both the statement and the signature. Others can use the public key to verify the signature and make sure the statement really came from the private key owner.

Still a bit abstract? Let's do it with real steps.

Using openssl to Generate Key Pairs

We'll use the openssl command to generate a key pair. Most operating systems already have this tool installed.

First, generate a private key, which is unique. The public key will be extracted from the private key.

# Generate private key
openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048

• genpkey: Command to generate keys.
• -algorithm RSA: Use the RSA algorithm, a classic asymmetric algorithm.
• -out private_key.pem: Save the generated private key to private_key.pem.
• -pkeyopt rsa_keygen_bits:2048: Set the key length to 2048 bits, which is recommended for security.

After running this, a file named private_key.pem will appear in the folder. This is your private key. You must keep it safe!

Now, generate the public key from the private key:

# Generate public key
openssl rsa -pubout -in private_key.pem -out public_key.pem

• rsa: The command for working with RSA keys.
• -pubout: Output the public key.
• -in private_key.pem: Specify the private key file.
• -out public_key.pem: Save the public key to public_key.pem.

Now you have the public_key.pem file, which is your public key. You can share it with anyone.

Using for Encryption and Decryption

Suppose the sender wants to send you a secret message:

echo "My name is Bob." > message.txt

He can use your public key to encrypt the message:

# Encrypt with public key
openssl pkeyutl -encrypt -pubin -inkey public_key.pem -in message.txt -out encrypted_message.bin

• -encrypt: Perform encryption.
• -pubin -inkey public_key.pem: Use the public key (public_key.pem).
• -in message.txt: The file to encrypt.
• -out encrypted_message.bin: Output the encrypted content to encrypted_message.bin.

Now, there is a new file encrypted_message.bin with unreadable content. This is the ciphertext.

You can decrypt the ciphertext using your private key:

# Decrypt with private key
openssl pkeyutl -decrypt -inkey private_key.pem -in encrypted_message.bin -out decrypted_message.txt

• -decrypt: Perform decryption.
• -inkey private_key.pem: Use your private key (private_key.pem).
• -in encrypted_message.bin: The encrypted file to decrypt.
• -out decrypted_message.txt: Output the decrypted message to decrypted_message.txt.

To check the decrypted content:

cat decrypted_message.txt

You will see: My name is Bob.

Scenario 2: Signing and Verifying

Suppose you want to publish a statement, like a contract:

echo "I agree." > contract.txt

To prove this contract is really signed by you, you can use your private key to create a digital signature for contract.txt.

# Sign with private key
openssl dgst -sha256 -sign private_key.pem -out signature.bin contract.txt

• dgst -sha256: First use SHA256 to hash the file, then sign the hash.
• -sign private_key.pem: Use your private key to sign.
• -out signature.bin: Save the signature to signature.bin.
• contract.txt: The file to sign.

Next, you can publish both contract.txt (the text) and signature.bin (the signature). Anyone with your public key (public_key.pem) can verify the signature:

# Verify signature with public key
openssl dgst -sha256 -verify public_key.pem -signature signature.bin contract.txt

• -verify public_key.pem: Use your public key to verify.
• -signature signature.bin: The signature to verify.
• contract.txt: The file to check.

If the command succeeds, you will see:

Verified OK

This means:

• Identity is real: The signature was created by the person with the private key matching the public key.
• Data is complete: The content of contract.txt has not been changed since it was signed.

You can try changing contract.txt or use another private key to make signature.bin. Then run the verify command again, and you will see:

Verification Failure