5.4 Asymmetric Cryptography

Symmetric encryption has one big weakness: both people need the same secret key, and somehow they have to share it without anyone else getting it. Asymmetric cryptography solves that problem with a clever trick. Instead of one shared key, each person gets a pair of keys that work together as mathematical opposites. This is the system that lets you safely send your credit card info to a website you've never visited before, and it's the backbone of secure communication on the internet.

How Asymmetric Encryption Works

Asymmetric encryption lets two people communicate securely without ever agreeing on a shared secret ahead of time. That's the whole point. With symmetric encryption, you and your friend both need the same key, which means you have to meet up or find some other safe way to exchange it first. Asymmetric encryption skips that step entirely.

Here's how it works. Anyone who wants to receive encrypted messages first generates a key pair. A key pair is two binary strings of equal length, created together through a mathematical process. One key gets labeled the public key and the other becomes the private key.

These keys are mathematical inverses of each other. That means whatever one key encrypts, only the other key in the pair can decrypt. Either key can do the encrypting, but its partner is the only thing that can undo it. A key can't decrypt something it encrypted itself.

Public vs. Private Keys

The names tell you exactly how to handle each key:

• The public key is meant to be shared. You can post it on your website, email it around, or publish it in a directory. Anyone who wants to send you a secure message needs it.
• The private key must stay secret. Store it somewhere safe (an encrypted file, a hardware security module, a password manager). The entire security of the system depends on this key staying private.

If your private key ever gets exposed, stolen, corrupted, or shared (even by accident), the whole key pair is burned. You have to delete it and generate a new one. There's no recovering from a leaked private key, because anyone who has it can decrypt every message that was sent to you.

Choosing the Right Key

This is where students often get tripped up. Which key do you use, and when? The rule is simple once you see the pattern:

To send an encrypted message to someone, use their public key. Only they have the matching private key, so only they can decrypt it.

Let's walk through an example. Say you want to send a confidential file to your friend Maya.

1. Maya generates a key pair. She keeps her private key locked down on her laptop and publishes her public key online.
2. You download Maya's public key.
3. You encrypt the file using Maya's public key.
4. You send the encrypted file to Maya (even over an unsecured channel like regular email).
5. Maya decrypts it using her private key.

Even if an attacker intercepts the encrypted file, they can't read it. They don't have Maya's private key, and her public key (the only thing they have) can't undo its own encryption.

Flip the scenario: if Maya wants to send something back to you, she uses your public key, and you decrypt with your private key. Each person needs their own key pair.

Quick Reference

Why Key Length Matters

The security of encryption depends heavily on how long the key is. Longer keys are harder to crack, but they also take longer to use. There's a tradeoff.

Keyspace and Brute Force

A keyspace is the total number of possible keys for a given key length. For binary keys, an n-bit key has a keyspace of $2^n$.

So a 4-bit key has $2^4 = 16$ possible values. A 128-bit key has $2^{128}$ possible values, which is a number with 39 digits. A 2048-bit RSA key has a keyspace so enormous that it makes the number of atoms in the observable universe look small.

If an attacker tries to brute-force a key by guessing randomly, on average they'll find it after checking about half the keyspace. That's $2^n / 2$ or $2^{n-1}$ guesses. Even with a fast computer, this becomes impossible for large keys. A 256-bit key would take longer than the age of the universe to brute-force with current technology.

The Tradeoff

Longer keys aren't free. They take more processing power to generate, encrypt with, and decrypt with. On a phone or low-power device, using a giant key can slow things down noticeably. That's why you pick a key length that's secure enough for your needs without being overkill.

Keys Get Longer Over Time

Computers keep getting faster. What was considered uncrackable 20 years ago can be broken much more quickly today. Because of this, recommended key lengths keep going up. RSA used to be considered secure at 1024 bits. Now 2048 bits is the minimum, and 4096 bits is common for high-security uses. This applies to both symmetric and asymmetric algorithms.

Comparing Key Lengths Fairly

Here's an important catch: you can only directly compare key lengths within the same algorithm. For example:

• An AES 256-bit key is more secure than an AES 128-bit key. ✅
• An RSA 4096-bit key is more secure than an RSA 2048-bit key. ✅
• An RSA 2048-bit key is more secure than an AES 128-bit key. ❌ (You can't say this.)

Why? Different algorithms use their key bits differently. RSA needs much longer keys than AES to reach a similar level of security because the math behind RSA can be attacked in ways that don't apply to AES. A 2048-bit RSA key offers roughly the same security as a 112-bit symmetric key. Comparing bit lengths across algorithms gives you the wrong answer.

Common Asymmetric Algorithms

Two algorithms come up most often:

• RSA (Rivest, Shamir, Adleman): The classic asymmetric algorithm. Its security relies on the difficulty of factoring very large numbers into primes. Common key sizes are 2048 and 4096 bits.
• Elliptic Curve Cryptography (ECC): A newer approach that uses the math of elliptic curves. ECC can offer the same security as RSA with much shorter keys, which makes it faster and more efficient. A 256-bit ECC key is roughly as secure as a 3072-bit RSA key.

Asymmetric algorithms are used for more than just sending secret messages. They also power digital signatures (proving a message really came from you) and digital certificates (the things that make HTTPS work in your browser).

Using Asymmetric Encryption in Practice

You can encrypt and decrypt with asymmetric algorithms using command-line tools, specialized software like RSA Encryption Tool, or web-based tools. The most common command-line tool is OpenSSL, which comes installed on most Linux and macOS systems and is available for Windows.

Generating an RSA Key Pair

To create a 2048-bit RSA key pair and save it to a file called rsa.pem:

</>Code
openssl genrsa -out rsa.pem 2048

The rsa.pem file contains both keys (public and private). Treat this file like a password. If someone gets it, they have your private key.

Extracting the Public Key

You don't want to hand out the file that contains your private key. You need to pull just the public key into its own file. To extract the public key from rsa.pem and save it to public.pem:

</>Code
openssl rsa -pubout -in rsa.pem -outform PEM -out public.pem

Now public.pem is safe to share with anyone. They'll use it to encrypt messages for you.

Encrypting a File

Say someone wants to send you a file called test. They use your public.pem to encrypt it:

</>Code
openssl pkeyutl -encrypt -pubin -inkey public.pem -in test -out test.enc

The -pubin flag tells OpenSSL that the input key is a public key. The encrypted output gets saved as test.enc. They send test.enc to you over any channel they want, even an insecure one.

Decrypting a File

When you receive test.enc, you decrypt it with your private key file:

</>Code
openssl pkeyutl -decrypt -inkey rsa.pem -in test.enc -out test

This reverses the encryption and gives you back the original test file. Notice you used rsa.pem (which contains your private key) for decryption, not public.pem.

Putting It All Together

A full workflow for receiving a secure file looks like this:

1. Generate your key pair with openssl genrsa.
2. Extract your public key with openssl rsa -pubout.
3. Share public.pem with the sender. Keep rsa.pem locked away.
4. The sender encrypts the file with your public key using openssl pkeyutl -encrypt.
5. They send you the encrypted file.
6. You decrypt it with your private key using openssl pkeyutl -decrypt.

The beauty of this whole system is that steps 3 and 5 can happen in the open. The public key being public is the whole point. As long as your private key stays private, the messages stay safe.