5.4 - Asymmetric Cryptography

Why Asymmetric Encryption Matters

Symmetric encryption has one major headache: how do you securely get the shared key to the other party in the first place, especially if you've never met and have no secure channel between you? Asymmetric encryption solves this cleanly. Each person generates a mathematically related key pair, a public key they can freely share with anyone (websites, key servers, email signatures), and a private key they keep completely secret. Anyone can use someone's public key to encrypt a message meant for them, but only the matching private key can decrypt it.

Each person who's going to receive encrypted data generates their own key pair first. The two keys are binary strings of equal length, generated at the same time through a mathematical process, and they're mathematical inverses of each other: each key reverses what its partner does. Either key can be used to encrypt, but only the other key in the pair can decrypt the result. One key is designated the public key and published for anyone to view and use. The other is the private key, and it has to be stored securely, since the security of the whole system rests on it staying private.

Example flow: Bob generates a key pair and publishes his public key openly while carefully guarding his private key. Alice grabs Bob's public key, encrypts her message with it, and sends the resulting ciphertext to Bob, safe to send over any insecure channel since it's useless without Bob's private key. Bob decrypts it using his private key, and since only he has that private key, only he can read the message. Even if someone intercepts the public key (doesn't matter, it's meant to be public) or the ciphertext itself (useless without the private key), the message stays protected.

Which key to use: it depends on the goal.

Goal	Encrypt with	Decrypt with
Send Bob a secret message	Bob's public key	Bob's private key (only Bob has it)
Read a secret message someone sent you	Your public key (the sender used it)	Your private key
Prove a message came from you (a digital signature)	Your private key	Your public key (so anyone can check it)

The rule for keeping something secret: encrypt with the receiver's public key. Your own private key is the wrong choice for secrets, since anyone with your public key (which is everyone) could decrypt it, and the receiver's private key isn't an option because only the receiver has it.

If a private key ever gets exposed or stolen, the response needs to be immediate: revoke the compromised key pair right away, delete both keys, generate a fresh key pair, publish the new public key, and notify all your contacts about the change. This matters because anyone holding a stolen private key can decrypt every past and future message encrypted with the matching public key, and can potentially impersonate that person too. For example, if someone's laptop containing an unencrypted private key gets stolen, an attacker could decrypt every intercepted message ever sent to that person and even forge that person's digital signature, meaning the only real fix is revoking the compromised key, generating a properly protected new one, and letting everyone know to switch over.

Key Length and Security

Just like symmetric keys, a longer asymmetric key means a larger keyspace and stronger security, but also slower performance since more computation is required. On average, brute forcing a key takes about half the total keyspace worth of guesses, meaning even a 128-bit key would take on the order of 10^21 years at a billion guesses per second, and a 2048-bit key is so astronomically large that brute force is simply not a realistic threat at all.

In numbers: for binary keys, an n-bit key has a keyspace of

2^n

. Guessing at random, an adversary finds the right key, on average, about halfway through, which is

2^n/2 = 2^{n-1}

guesses. Every extra bit doubles the keyspace, so it also doubles the average time to guess the key. At a billion guesses per second:

Key length	Keyspace	Average guesses	Average time
8-bit	$2^8 = 256$	$2^7 = 128$	Well under a millionth of a second
40-bit	$2^{40} \approx 1.1$ trillion	$2^{39} \approx 550$ billion	About 9 minutes
41-bit	$2^{41} \approx 2.2$ trillion	$2^{40} \approx 1.1$ trillion	About 18 minutes
56-bit (old DES)	$2^{56} \approx 7.2 \times 10^{16}$	$2^{55} \approx 3.6 \times 10^{16}$	About 1.1 years
128-bit	$2^{128} \approx 3.4 \times 10^{38}$	$2^{127} \approx 1.7 \times 10^{38}$	About $5.4 \times 10^{21}$ years

That's why 40-bit encryption counts as weak (it's the "small key" in Topic 5.1's moderate risk example), and why each added bit matters.

Because computing power keeps improving, recommended key lengths have crept upward over the decades, from 512-bit RSA being considered secure in the 1990s, to 1024-bit in the 2000s, to 2048-bit becoming the accepted minimum by the 2010s, with 4096-bit now recommended for anything needing long-term protection. Current guidance generally treats AES-128 as acceptable and AES-256 as preferred for sensitive symmetric data, while for RSA, 2048-bit is the bare minimum, 3072-bit offers solid protection, and 4096-bit is the top tier; ECC achieves equivalent security to RSA using much shorter keys (a 256-bit ECC key is roughly equivalent to a 3072-bit RSA key), making it notably more efficient.

Importantly, you can only meaningfully compare key lengths within the same algorithm, since different algorithms rely on entirely different mathematical foundations (RSA relies on how hard prime factorization is, AES relies on substitution-permutation networks), so comparing something like RSA-2048 to AES-128 directly doesn't really mean anything.

Common Asymmetric Algorithms

RSA is the most widely used asymmetric algorithm, based on how difficult it is to factor a huge number back into the two large prime numbers that were multiplied together to make it, typically used with 2048, 3072, or 4096-bit keys for encryption, digital signatures, and key exchange, and it underpins things like SSL/TLS, PGP, and SSH.

ECC (Elliptic Curve Cryptography) is based on the elliptic curve discrete logarithm problem, achieving equivalent security to RSA with much shorter keys (commonly 256, 384, or 521 bits), making it more efficient, which is why it's popular in things like Bitcoin, modern TLS, and mobile devices where efficiency matters more.

Beyond basic encryption, asymmetric cryptography also enables digital signatures (proving authenticity and integrity), digital certificates (the backbone of SSL/TLS for websites), secure key exchange, and authentication without ever revealing an actual secret.

A digital signature uses the key pair the other way around. The sender takes a hash of the message and encrypts it with their own private key, then attaches it. Anyone can decrypt the signature with the sender's public key and compare it to the message's hash. If they match, the message really came from the private key's owner and wasn't changed along the way.

A digital certificate is a file that ties a public key to an identity, like a website's domain name, and is digitally signed by a trusted organization called a certificate authority (CA). It's how your browser knows the public key it receives really belongs to the site you meant to visit.

Practical RSA with OpenSSL

Like symmetric encryption, asymmetric encryption and decryption can be done on the command line (with OpenSSL), with specialized software (like RSA Encryption Tool), or with web-based tools. Web tools are fine for practice files, but never paste a real private key into a website, since that hands your private key to whoever runs it.

Generating a new RSA key pair looks like openssl genrsa -out rsa.pem 2048, which creates a file containing both the private and public key components together, at a 2048-bit key length. This file needs serious protection, since it contains the private key, through proper file permissions, encryption, or secure storage.

Extracting just the public key for sharing looks like openssl rsa -pubout -in rsa.pem -outform PEM -out public.pem, which pulls the public portion out into its own separate file. That resulting public.pem file is completely safe to email, post publicly, or share however's convenient, while the original rsa.pem needs to stay secret.

Encrypting a file with someone's public key looks like openssl pkeyutl -encrypt -pubin -inkey public.pem -in test -out test.enc, producing an encrypted output that can only be decrypted using the matching private key. Decrypting it back looks like openssl pkeyutl -decrypt -inkey rsa.pem -in test.enc -out test_decrypted, using the private key instead (and dropping the -pubin flag), which restores the original content.

Here are all four commands together, in the order they're used:


# Bob (the receiver) runs these once, then shares only public.pem
openssl genrsa -out rsa.pem 2048
openssl rsa -pubout -in rsa.pem -outform PEM -out public.pem

# Alice (the sender) encrypts with Bob's public key
openssl pkeyutl -encrypt -pubin -inkey public.pem -in test -out test.enc

# Bob decrypts with his private key
openssl pkeyutl -decrypt -inkey rsa.pem -in test.enc -out test_decrypted

A complete workflow might look like Bob generating his key pair once and sharing only his public key with Alice through email or a website, keeping his private key protected. Alice encrypts a document using Bob's public key and sends the encrypted file over email, perfectly safe since it's unreadable without Bob's private key. Bob receives it and decrypts it locally using his private key to get the original document back.

There are real practical limits here worth knowing. RSA can only encrypt data smaller than its key size (a 2048-bit key tops out around 245 bytes), so for anything larger, the standard approach is hybrid encryption: generate a random symmetric AES key, use that fast symmetric key to encrypt the actual large file, then use RSA just to encrypt that small symmetric key itself, sending both pieces together. The recipient decrypts the small symmetric key first with their RSA private key, then uses that to decrypt the actual file. This matters because RSA is dramatically slower than symmetric encryption for bulk data (something AES could encrypt in seconds might take RSA hours), so in the real world, RSA gets used for the initial key exchange while AES handles the actual heavy lifting. Good key management practices include protecting your private key with a strong passphrase, keeping a secure offline backup, using hardware tokens like a YubiKey when possible, never transmitting a private key over a network, and publishing public keys through key servers or verified channels with fingerprint verification.

Real-World Applications

SSL/TLS (HTTPS) works by having your browser request a site, the server responding with a certificate containing its public key, the browser verifying that certificate, generating a random symmetric session key, encrypting that session key with the server's public key, and the server decrypting it with its private key, after which both sides switch to fast symmetric encryption for the rest of the session.

PGP/GPG email encryption works the same basic way: users generate and publish key pairs, senders encrypt messages using the recipient's public key, and only the recipient's private key can decrypt them, meaning email providers along the way only ever see ciphertext.

SSH authentication places your public key on a server (typically in an authorized_keys file) while your private key stays on your own machine, letting you log in by proving you hold the matching private key, entirely without needing a password.

Summary

Asymmetric encryption's big advantage is solving the key distribution problem entirely, no pre-shared secret is ever needed, and it's the foundation of digital signatures, certificates, and essentially all of internet security. The public key gets shared freely while the private key stays absolutely secret, and if it's ever compromised, it has to be revoked and replaced immediately. Longer keys mean stronger security at the cost of speed, and recommended key lengths keep growing as computing power increases. In practice, real systems almost always combine RSA or ECC for key exchange with fast symmetric encryption like AES for the actual bulk data, giving the best combination of security and performance.

Back Next