Understanding Asymmetric Cryptography: Encryption vs. Digital Signatures

It’s a common point of confusion in the world of cryptography: how can public and private keys seem to play opposite roles when comparing data encryption and digital signatures? If a public key can encrypt data that only the private key can decrypt, how can a private key create a signature that the public key can verify? Doesn’t that sound backward?

Let’s break down these two core concepts of asymmetric cryptography side-by-side to clear things up.

Part 1: Asymmetric Encryption - Keeping Secrets Safe

The primary goal of asymmetric encryption is confidentiality. You want to send information securely, ensuring only the intended recipient can read it.

How it Works:

1. Recipient’s Keys: The recipient has a pair of keys: a public key they share freely and a private key they keep absolutely secret.
2. Encryption: You (the sender) take your message ($M$) and use the recipient’s public key to encrypt it. This transforms the message into unreadable ciphertext ($C$).
   • Think of the public key as an open padlock. Anyone can snap it shut (encrypt), but it can’t be opened with the same key.
3. Decryption: The recipient receives the ciphertext ($C$) and uses their secret private key to decrypt it, revealing the original message ($M$).
   • Only the corresponding private key can open the padlock.

Key Idea: The public key encrypts for confidentiality; the private key decrypts.

Part 2: Digital Signatures - Proving Authenticity and Integrity

Digital signatures serve a different purpose: authenticity (proving who sent the message) and integrity (proving the message hasn’t been tampered with). It’s not about keeping the message secret, but about verifying its origin and state.

How it Works:

1. Sender’s Keys: This time, the sender uses their key pair. They have a private key (secret) and a public key (shared).
2. Hashing: The sender first creates a condensed representation of the message called a hash ($H(M)$). This hash is unique to the specific message content.
3. Signing: The sender then uses their private key to “sign” this hash. This usually involves encrypting the hash value with the private key, creating the digital signature ($S$).
   • Think of this as applying a unique, unforgeable seal using the private key.
4. Sending: The sender sends the original message ($M$) along with the digital signature ($S$).
5. Verification: The receiver uses the sender’s public key to verify the signature. This involves two steps:
   • a. Decrypt the received signature ($S$) using the sender’s public key. This should reveal the original hash ($H(M)$) created by the sender.
   • b. Independently calculate the hash of the received message ($M$).
   • c. Compare the hash from step (a) with the hash from step (b). If they match, the signature is valid! This confirms the message came from the owner of the private key and hasn’t been altered.

Key Idea: The private key signs (the hash) for authenticity; the public key verifies.

Why Can’t the Public Key Create the Signature?

This is the crux of the confusion. If the public key can encrypt, why can’t it perform the signing step?

The answer lies in the underlying mathematics of asymmetric algorithms like RSA. Encryption/Decryption and Signing/Verification are related but distinct mathematical operations, even though they use the same key pair.

• Public Key Roles:
  • Encrypts data for confidentiality (an operation only reversible by the private key).
  • Verifies a signature (reverses the private key’s signing operation).
• Private Key Roles:
  • Decrypts data for confidentiality (reverses the public key’s encryption operation).
  • Signs data (or its hash) for authenticity (an operation only reversible by the public key).

These operations are designed as one-way functions working in specific pairs:

• Public Key Encrypt $\rightarrow$ Private Key Decrypt
• Private Key Sign $\rightarrow$ Public Key Verify

The mathematical function used for signing with the private key is different from the function used for encrypting with the public key. The public key simply doesn’t have the mathematical capability to perform the “signing” operation; it can only perform the “verification” operation which is its inverse.

Think of it like two different locks using the same key blanks but cut differently:

• Lock A (Encryption): Can only be locked by the Public Key cut, and only unlocked by the Private Key cut.
• Lock B (Signing): Can only be locked by the Private Key cut, and only unlocked by the Public Key cut.

The Public Key can unlock Lock B (verify), but it cannot lock it (sign).

A Peek Under the Hood: RSA Example

Let’s briefly look at the RSA algorithm (using simplified notation):

Keys:

• Public Key: ($e$, $n$)
• Private Key: ($d$, $n$)

Encryption (Confidentiality):

• Sender uses Recipient’s Public Key ($e, n$): $C = M^e \mod n$
• Recipient uses their Private Key ($d, n$): $M = C^d \mod n$

Digital Signature (Authenticity):

• Sender hashes message: $H(M)$
• Sender uses their Private Key ($d, n$) to sign the hash: $S = (H(M))^d \mod n$
• Receiver uses Sender’s Public Key ($e, n$) to verify:
  1. Calculate $V = S^e \mod n$
  2. Independently calculate $H(M)$ from the received message.
  3. Check if $V == H(M)$.

Notice how the exponents $e$ and $d$ are used in different places for encryption/decryption versus signing/verification. This mathematical distinction prevents the public key ($e$) from being able to compute the signature ($S = (H(M))^d \mod n$).

(Conceptual) Hypothetical Simple Example: SimpleMod

Disclaimer: The following is a highly simplified, non-secure example purely to illustrate the concept of different operations, not for practical use. It doesn’t have the perfect inversion properties of real algorithms like RSA.

Keys:

• Public Key: ($p=7, q=3$)
• Private Key: ($q=3, p=7$)

Encryption: (Using Public Key $p=7, q=3$)

• $C = (M \times p) \mod q$
• Example $M=4$: $C = (4 \times 7) \mod 3 = 28 \mod 3 = 1$

Decryption: (Using Private Key $q=3, p=7$)

• $M = (C \times q) \mod p$
• Example $C=1$: $M = (1 \times 3) \mod 7 = 3 \mod 7 = 3$ (Doesn’t match original M=4 - highlights the example’s imperfection)

Signing: (Using Private Key $q=3, p=7$)

• $S = (M \times q) \mod p$
• Example $M=4$: $S = (4 \times 3) \mod 7 = 12 \mod 7 = 5$

Verification: (Using Public Key $p=7, q=3$)

• $V = (S \times p) \mod q$
• Example $S=5$: $V = (5 \times 7) \mod 3 = 35 \mod 3 = 2$ (Doesn’t match original M=4)

Even though this simplistic algorithm doesn’t work perfectly, it demonstrates using the same numbers ($p, q$) in different roles for the distinct processes of encryption/decryption and signing/verification. This conceptual separation is the key takeaway.

Conclusion: Two Sides of the Same Coin

Asymmetric cryptography uses a single key pair for two vital but distinct functions:

1. Encryption/Decryption (Confidentiality): Public key locks, Private key unlocks.
2. Signing/Verification (Authenticity/Integrity): Private key seals (signs hash), Public key checks the seal (verifies).

The confusion usually dissolves when you realize that “encrypting” for confidentiality and “signing” for authenticity are different mathematical operations, cleverly designed to work inversely using the public/private key pair. The public key can verify a signature precisely because the algorithm defines verification as the inverse of the private key’s signing operation, an operation the public key itself cannot perform.