Public Key & Private Key: The Cryptography Behind Secure Connections

Every time you connect to a remote server, push code to GitHub, or visit an HTTPS website, asymmetric cryptography is silently protecting you. At the heart of it is a simple but powerful idea: a key pair — one public, one private — where only the matching private key can prove ownership of the public one.

---

🔓 The Problem with Passwords

Passwords have a fundamental flaw: they must travel across the network (or be hashed and compared on the server). This creates risk:

• Brute-force and dictionary attacks
• Credential stuffing from breached databases
• Phishing for the password directly
• Server-side storage vulnerabilities

Note: Public key cryptography eliminates most of these attack surfaces. The secret never leaves your machine.

---

🔑 Asymmetric Cryptography: The Core Idea

Traditional symmetric encryption uses a single shared key — both sides need the same secret. Asymmetric encryption uses a mathematically linked pair:

The crucial property: you cannot derive the private key from the public key. The math makes it computationally infeasible — even with modern hardware, it would take longer than the age of the universe.

The Padlock Analogy

Think of the public key as an open padlock you hand out freely. Anyone can lock a message inside a box using your padlock. But only you hold the key that opens it. Publishing your padlock doesn't help anyone else open locked boxes.

---

🧮 How the Math Works: Ed25519

Modern SSH uses Ed25519, an elliptic curve algorithm. Here's the intuition:

1. You pick a secret number $d$ (your private key)
2. You multiply a known base point $G$ on the elliptic curve by $d$: $Q = d \times G$ (your public key)
3. Given $Q$ and $G$, finding $d$ is the Elliptic Curve Discrete Logarithm Problem — computationally hard

The "multiplication" here isn't ordinary multiplication — it's point addition on the curve, repeated $d$ times. Going forward (private → public) is fast. Going backward (public → private) is effectively impossible.

Ed25519 offers:

• 256-bit keys with security equivalent to 3072-bit RSA
• Fast signing (~100,000 signatures/second)
• Resistance to side-channel attacks
• No weak parameter choices (unlike some RSA implementations)

---

🔐 SSH Key Authentication: Step by Step

sequenceDiagram
    participant C as Client
    participant S as Server

    C->>S: "I want to log in as root"
    S->>S: Check authorized_keys for public key ✓
    S->>C: Challenge (random nonce)
    C->>C: Sign nonce with private key
    C->>S: Signed response
    S->>S: Verify signature with public key ✓
    S->>C: Access granted ✅

The password never exists in this exchange. The private key never leaves the client. Even if someone intercepts the entire conversation, they gain nothing useful.

---

⚙️ Generating an Ed25519 Key Pair

Linux / macOS / Windows (PowerShell or Git Bash):

ssh-keygen -t ed25519 -C "your@email.com"

This creates two files:

• ~/.ssh/id_ed25519 — private key (600 permissions, never share this)
• ~/.ssh/id_ed25519.pub — public key (safe to share freely)

Adding your public key to a server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server.com
# or manually:
cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys

---

🛡️ Security Best Practices

Protect your private key

• Use a passphrase when generating — encrypts the key file at rest
• Store it only on trusted devices
• Never paste it anywhere, never email it, never commit it to git

Danger: Committing your private key to git — even for a second — is a critical security incident. Rotate it immediately and audit access logs.

On the server side

Once key auth is confirmed working, disable password authentication entirely:

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin prohibit-password

Then restart SSH:

systemctl restart sshd

This closes the door to brute-force attacks completely.

Use ssh-agent for convenience

Rather than typing your passphrase every time:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

The agent holds your decrypted key in memory for the session.

---

📊 Key Types: A Quick Comparison

---

🌐 Beyond SSH: Where Else Are These Keys Used?

Asymmetric cryptography is everywhere:

• HTTPS/TLS — your browser verifies a website's certificate (public key) before sending data
• Code signing — Git commit signatures, software package verification
• PGP/GPG — email encryption, file signing
• Hardware security keys (YubiKey) — the private key lives on tamper-resistant hardware, never exposed to the OS
• Blockchain — wallet addresses are derived from public keys; transactions are signed with private keys

---

💡 Summary

Public key cryptography is one of the most elegant ideas in computer science. A pair of mathematically linked numbers — one public and one private — eliminates the need to ever transmit a secret over the network.

---

Part of my server security hardening series. Next: setting up UFW firewall rules and Fail2ban for brute-force protection.