Asymmetric Cryptography

Beginner-friendly guide

1 Introduction


Public/private key pairs, also known as asymmetric cryptography are fundamental to secure communication, digital signatures, and authentication methods such as SSH logins. This walkthrough is aimed at readers with some prior exposure to IT security or cryptography, as it uses terminology that assumes basic familiarity with the subject. My goal is to explain what these keys actually represent, how they are generated, how to keep them secure, and how they are used in real-world scenarios.

Much of what follows is based on my own research, experimentation, and university lab work. Public and private keys are not “passwords” or “hashes,” but large numbers produced through mathematical algorithms, one of the most widely used beingRSA.

This note is structured in two parts. First, I outline the underlying ideas and mathematical concepts that make asymmetric cryptography work. Then, I move on to the practical side, how to create key pairs with OpenSSL and how to use them securely. While the theoretical section isn’t strictly required to generate or use keys, understanding it provides important insight into why these systems are trustworthy.

1.1 Rivest–Shamir–Adleman Algorithm

The RSA method, named after its inventors Ronald Rivest, Adi Shamir, and Leonard Adleman, is one of the best-known asymmetric encryption techniques. It is a public key system in which a public key is shared for encryption, while the private key used for decryption remains secret. What are these keys? They are large numbers generated by mathematical algorithms and typically represented as character strings. RSA key pairs have the following properties:

  • The public key can encrypt a message (e.g., “Hello Bob!” → “HbcAIhdakbASDoD”).
  • The private key can decrypt that message, recovering the original text.
RSA and similar methods are used in secure communication systems such as online banking and credit card transactions via TLS/SSL. The mathematical foundation of RSA involves modular arithmetic and number theory, particularly Euler’s theorem. If math isn’t your thing, feel free to skip the details. Here are the steps of the RSA procedure:

  1. Choose two distinct large prime numbers p and q, then compute k $$k = p \cdot q$$
  2. Afterwards compute a value m $$m = (p-1)(q-1)$$
  3. Choose a number e such that $$1 < e < m \quad \text{and} \quad \gcd(e, m) = 1$$
  4. Find a number d such that $$d \cdot e \equiv 1 \pmod{m}$$
    This can always be done with the Extended Euclidean Algorithm.
  5. The public key consists of the two numbers $$(e, k)$$
  6. The private key consists of the two numbers $$(d, k)$$
  7. Encryption: our information, that we want to encrypt, called plaintext and in this case number T (smaller than both p and q) is transformed into ciphertext G using the public key: $$G \equiv T^e \pmod{k}$$
  8. Decryption: the ciphertext G is transformed back into plaintext: $$T \equiv G^d \pmod{k}$$

1.2 OpenSSL

OpenSSL is an open-source toolkit that provides the building blocks for secure communication on the internet. It includes:

  1. A software library used by programs and web servers to handle encryption, digital signatures, and secure connections.
  2. A command-line tool (openssl) that lets you try out these cryptographic functions directly in Linux or macOS terminals.

In simple terms, OpenSSL is like a "toolbox" full of locks, keys, and secret codes that software uses to keep your data private and authentic.

RSA is one of the classic encryption methods that OpenSSL supports. When you use openssl to generate keys, encrypt a file, or create a digital signature, it is performing the RSA steps we described earlier, but automatically and securely.

  • Key Generation: OpenSSL creates two large secret prime numbers, then calculates the public and private keys $$(e, k)$$ and $$(d, k)$$
  • Encryption: OpenSSL uses the public key to transform a plaintext, in this case maybe a message into an unreadable ciphertext.
  • Decryption: Only the private key can reverse the process and recover the original message.

This is why OpenSSL is widely used: it brings the theory of RSA and other cryptographic algorithms into real applications to ensure that the messages we send are authentic and secure. There are also two main guarantees we need when talking about securely sending messages over the internet:

  • Authenticity & Integrity: Making sure that the message really comes from the actual sender and has not been changed on the way.
  • Confidentiality: Making sure that no one else can read the message except the intended receiver.

1.3 Keys vs. SSL/TLS

RSA by itself is just mathematics. With a public and a private key we can achieve two things:

  • Confidentiality: Encrypt a message with the public key so only the holder of the private key can read it.
  • Authenticity & Integrity: Use the private key to create a digital signature that anyone can verify with the public key, proving that the message really came from the sender and was not changed.

SSL/TLS (used in HTTPS) is the protocol that takes the ideas of public and private keys and applies them to real-world internet security. Its job is to make sure that keys can be exchanged securely, even over an open and untrusted network like the internet. You don’t need to know the inner workings here, but it’s useful to remember: once you understand RSA you might wonder, just like I did, “we have the keys, that makes sense, but how do we actually send them safely?” The answer is: with SSL or TLS.

In short: RSA and public/private keys are the building blocks, while SSL/TLS is the system that uses those building blocks (together with other techniques) to make secure communication on the internet possible.

1.4 Example: Alice and Bob

To make things more concrete, let’s imagine Alice wants to send Bob a message. Alice wants to make sure that nobody besides Bob can read her message. Her message is simply: "Hello, Bob!". How do public/private keys and SSL/TLS help?

  1. Key Creation: Bob generates a key pair using RSA: a public key and a private key. He keeps the private key secret but shares the public key with Alice.
  2. Encryption: Alice takes Bob’s public key and uses it to encrypt her message "Hello, Bob!". Now the message looks like random numbers (ciphertext).
  3. Decryption: Bob receives the ciphertext. Using his and only his private key, he can decrypt the ciphertext and recover Alice’s original message.
  4. Authenticity (optional): If Alice also wants Bob to know it was really her, she can add a digital signature using her own private key. Bob can then check this with Alice’s public key.
  5. SSL/TLS in practice: On the real internet, Alice and Bob don’t usually exchange long messages with RSA directly. Instead, RSA (or another public-key algorithm) is used to securely exchange a temporary secret key. That key is then used with fast symmetric encryption (like AES) for the actual conversation. This is what SSL/TLS does for us automatically when we connect to websites with HTTPS.
Story Map

Source 1: Visual overview of Alice securely sending a message to bob

In short: Alice and Bob don’t need to worry about all the math every time. RSA provides the math foundation, and SSL/TLS is the protocol that applies it so secure communication “just works” when they use HTTPS or other encrypted channels.

1.5 Common Questions

1. How come someone with the public key cannot mathematically go back to the private one?

Great question! The short answer is: the math is easy one way, but hard the other way. RSA is built on the idea of multiplying two large prime numbers. Multiplying primes is easy, but given only the product, finding the original primes again is extremely hard (this is called the factorization problem). The public key contains this big product, but without knowing the primes, you cannotefficientlycompute the private key. That's why RSA works: the math creates a “one-way door”.

2. Does a person always have one and only one public and private key for everything?

Not at all. People and systems can have many different key pairs depending on what they need. For example, you might have:

  1. One key pair for SSH logins.
  2. Another for email encryption and digital signatures.
  3. And yet another for website certificates (HTTPS).

Each key pair is like a separate “identity” or “tool” for a specific job. Keys don’t have to be reused across everything, in fact, it’s safer to keep them separate.

3. I’ve never generated key pairs in my life, why would I need this?

Keys are created and managed automatically by the operating system, web browsers, or applications. For example, when you visit an HTTPS website, your browser is already using keys behind the scenes without you noticing. That’s why you may never have had to generate them yourself.

However, if you want to learn how cryptography works, test security concepts, or create your own secure setups (for example, SSH logins to servers), then generating keys manually is necessary. In this walkthrough, we’ll explore exactly how to do that.

2 Prerequisites


You only need command-line access on macOS, Linux, or Windows (PowerShell with OpenSSL installed works fine). The examples rely on the OpenSSL toolkit because it ships with widely available distributions and gives you full control over the keys you create. You also need a file, in this case you can create a simple text file containing some information that you want to encrypt.

2.1 Tools to install

  • OpenSSL 1.1 or newer. Check availability with openssl version.
  • Optional: ssh-keygen (bundled with OpenSSH) if you plan to log in to servers.
  • A text editor to view key files (they are plain text in PEM format).
# Confirm OpenSSL is ready to use
openssl version

2.2 Choosing a key type

RSA keys remain the most broadly supported option, especially for TLS certificates and encrypted email. For new SSH setups, Ed25519 keys are smaller and stronger against brute-force attacks. Elliptic-curve keys (for example prime256v1) provide similar strength with shorter key material but are not always accepted by legacy systems. This guide highlights both RSA and Ed25519 so you can pick what matches your tooling.

3 Generate a private key


Start by creating the private key file. Usually keys are supposed to be kept safe, in a location such as ~/.keys with restricted permissions. For testing purposes, you can keep it in the same folder or somewhere easily accesible to you. The command below creates a 4096-bit RSA key in PKCS#8 (PEM) format, which is the modern default in OpenSSL.

# Create a 4096-bit RSA private key
mkdir -p ~/.keys
openssl genpkey -algorithm RSA \
  -pkeyopt rsa_keygen_bits:4096 \
  -out ~/.keys/id_rsa.pem

3.1 Add a passphrase

Protecting the private key with a passphrase ensures that a stolen file alone is not enough to impersonate you. Use a long, memorable sentence instead of a short password. OpenSSL offers several ciphers; -aes-256-cbc balances compatibility and security.

# Re-run the command with encryption enabled
openssl genpkey -algorithm RSA \
  -pkeyopt rsa_keygen_bits:4096 \
  -aes-256-cbc \
  -out ~/.keys/id_rsa_protected.pem

4 Derive and inspect the public key


Once you have a private key, derive its public counterpart. You can safely share the public file with collaborators, servers, or certificate authorities. Inspecting both keys verifies that the files contain what you expect.

  • Use openssl pkey -pubout to create the public key.
  • Run openssl pkey -text -noout to print details for auditing.
  • If you generated a passphrase-protected key, OpenSSL will ask for the passphrase when reading it.
# Derive the matching public key
openssl pkey -in ~/.keys/id_rsa.pem \
  -pubout \
  -out ~/.keys/id_rsa.pub.pem

# Print a human readable summary
openssl pkey -in ~/.keys/id_rsa.pem -text -noout

5 Protect your key pair


A secure key pair is only trustworthy when the private part stays private. Combine operating system permissions with personal good habits.

  • Restrict filesystem access: chmod 600 ~/.keys/id_rsa.pem allows only you to read or write the file.
  • Keep backups offline. USB keys stored in safe places help you recover if your laptop fails.
  • Never email a private key. If you must transfer it, use an encrypted channel or temporarily wrap it inside a password-protected archive.
  • Rotate keys periodically. Generating a fresh pair every year keeps the exposure window small.

6 Use the keys in practice


With both files ready, you can try a couple of real-world workflows to build intuition: encrypting data, signing messages, and authenticating to servers. Use a temporary folder while experimenting so that you do not accidentally leak sensitive material.

6.1 Encrypt and decrypt files

Public keys encrypt data that only the paired private key can read. The pkeyutl utility in OpenSSL performs raw public-key encryption and decryption. Because RSA works on small inputs, encrypt a symmetric key or short secret rather than entire large files.

# Encrypt a short message with the public key
echo "Launch window at 14:00." > message.txt
openssl pkeyutl -encrypt \
  -pubin -inkey ~/.keys/id_rsa.pub.pem \
  -in message.txt \
  -out message.enc

# Decrypt with the private key
openssl pkeyutl -decrypt \
  -inkey ~/.keys/id_rsa.pem \
  -in message.enc \
  -out message.dec.txt

6.2 Create and verify signatures

Digital signatures prove that a message came from you and was not modified after signing. The sender signs with the private key, while anyone with the public key can verify the signature. Pair the dgst command with a modern hash such as SHA-256.

# Sign the message hash
openssl dgst -sha256 -sign ~/.keys/id_rsa.pem \
  -out message.sig \
  message.txt

# Verify the signature with the public key
openssl dgst -sha256 -verify ~/.keys/id_rsa.pub.pem \
  -signature message.sig \
  message.txt

6.3 Log in over SSH

SSH handles public-key authentication automatically when key files live inside ~/.ssh. Although OpenSSL can create keys, the ssh-keygen utility saves them with the correct permissions, comments, and formats that servers expect. Use Ed25519 unless you specifically need RSA for legacy hardware.

  • Generate an SSH key: ssh-keygen -t ed25519 -C "laptop@home">.
  • Copy the public key to a server: ssh-copy-id user@example.com.
  • Add host entries in ~/.ssh/config so SSH picks the correct key for each server.

7 Troubleshooting and next steps


If a command fails, read the error carefully—OpenSSL usually hints at the fix. Here are the most common issues:

  • Wrong file format: Convert legacy PKCS#1 keys with openssl pkey -in old.pem -out new.pem.
  • Permission denied: Ensure the key file is readable by your current user and that no other process is holding a lock on it.
  • Passphrase forgotten: There is no recovery mechanism. Generate a new pair, update every service, and revoke the old public key.
  • Looking for automation: Incorporate key generation scripts into your provisioning tool (Ansible, Terraform, or shell scripts) so every environment follows the same hardening steps.

Keep practicing by setting up a local SSH server or by creating a test certificate authority. The more often you repeat the workflow, the more natural key management becomes.