During World War II, the German military invented the Enigma machine, which allowed them to encrypt and transmit military intelligence over radio networks, making it difficult for the Allies to intercept the content and prepare for incoming attacks. To crack it, the British intelligence agency assembled the smartest mathematicians from Cambridge and Oxford to break through this encryption. Among them was the famous Alan Turing, one of the founding fathers of modern computing.
Since then, information encryption and cybersecurity have become an extremely important discipline. One of its core questions is: How do we ensure that critical information is only accessed by authorized individuals?
Throughout history, humanity's exploration of this question has never ceased. Initially, people used door latches to achieve this. Ancient emperors would build deadly traps in their tombs to protect their treasures even after death. Later, people invented locks and keys, which evolved into usernames and passwords in the digital age, and now we have various forms of MFA, fingerprints, facial recognition, iris scanning, authenticator apps, and more.
Digital Signatures and Symmetric Encryption
In real life, people typically sign important documents at the bottom to confirm that they have read and agreed to the content. This practice is based on a consensus, that printed documents cannot have their content altered, and that human signatures cannot be replicated, or at least, both of these things are extremely difficult to do. In the realm of network communication, this is incredibly important because during client-server communication, both parties must verify each other's identity in real-time and block unauthorized access. Imagine if a hacker could impersonate any client to initiate transfer requests to a banking system—this would be an absolute disaster.
To solve this problem, for a long time the mainstream approach has been identity verification through JWT (JSON Web Tokens). We place the user's identity information in a JSON object, like this:
{
"sub": "1234567890", // Subject (user ID)
"name": "John Doe", // User name
"email": "john.doe@example.com",
"role": "admin", // User role
"iat": 1516239022, // Issued at (timestamp)
"exp": 1516242622 // Expiration time
}
Then we use a secret key to digitally sign it (typically using HS256), ensuring its content cannot be tampered with or forged. HS256 is an encrypted hash algorithm, if an attacker tampers with the token's content, the original signature becomes invalid; the attacker also cannot re-sign it because they don't have the signing key. In a normal user flow, every network request carries this token as a pass, and the server validates it to ensure the request comes from a legitimate user.
In this way, the problem of secure communication between client and server seems perfectly solved. Since the signing party and verifying party use the same key here, it's called "symmetric encryption."
Asymmetric Encryption
As business logic gradually becomes more complex, or when multi-party communication needs arise, the weaknesses of symmetric encryption begin to be exposed, because the signing party and verifying party need to hold the same key. As a result, if any party has a vulnerability that leads to the key being compromised, the entire system falls into danger. Key rotation also becomes tricky because the new key needs to be synchronized to all servers, and the risk of this entire process increases rapidly with the number of key distributions. Sometimes physical means are even required to ensure security.
Thus, a new encryption method called “Asymmetric Encryption” has gradually been more widely adopted. Its implementation is also quite simple: separate the keys of the signing party and verifying party into a private key and public key. The private key is used to sign tokens (using algorithms like RS256 or ES256), while the public key is used to verify tokens. (Note: asymmetric signatures are the opposite of asymmetric encryption. In asymmetric encryption, the public key is used for encryption and the private key for decryption.)
// Example: Signing with private key (server-side)
import jwt from "jsonwebtoken";
import fs from "fs";
const privateKey = fs.readFileSync("private-key.pem");
const payload = {
sub: "1234567890",
name: "John Doe",
email: "john.doe@example.com",
role: "admin",
};
const token = jwt.sign(payload, privateKey, {
algorithm: "RS256",
expiresIn: "1h",
});
// Example: Verifying with public key (any service)
import jwt from "jsonwebtoken";
import fs from "fs";
const publicKey = fs.readFileSync("public-key.pem");
try {
const decoded = jwt.verify(token, publicKey, {
algorithms: ["RS256"],
});
console.log("Token is valid:", decoded);
} catch (error) {
console.error("Token verification failed:", error);
}
The private key is only held on the core server, while the public key can be distributed publicly. Anyone can use the public key to verify that a token was indeed issued by the correct server—but since they don't have the private key, they cannot sign any tokens, and therefore cannot tamper with or forge them.
So what's the mechanism behind asymmetric encryption? This is typically implemented through a class of special mathematical problems, such as prime factorization of large numbers and elliptic curve equations. The characteristic of these problems is that finding an answer is extremely difficult, often requiring supercomputers to iterate for hundreds of years—while verifying an answer is very simple, requiring only a single calculation.
For example, I can easily select two large prime numbers p and q from a prime number table in random as the private key, perform a multiplication operation on them, and then use the result n (a semiprime, typically >2048 digits) as the public key (some details are omitted here for clarity). It's very difficult for an attacker to find p and q from n, and it’s even been proven computationally impossible on traditional computers. Using this difficulty gap makes it safe from attackers compromising the private key, while verifiers can easily validate the signature's legitimacy.
Since the verification public key is public, the distribution process is much simpler and can be done directly through network channels without worrying about leaks. If the private key is compromised, it can be immediately rotated and the new public key redistributed. The easiest way to do this is just annoucing the public key in a JSON file and host it (often at /.well-known/jwks.json), then any service can fetch it and verify the signature with the public key. This is called JWKS (JSON Web Key Set), and the network communication security between servers is greatly ensured with it.
The Future Direction
This is certainly not the end of the story. As technology continues to develop, the security of asymmetric encryption is also gradually being challenged. For example, the emerging quantum computing technology has been proven to have many special algorithms that can greatly reduce the time needed to crack such special mathematical problems. For instance, Shor's algorithm can reduce the time complexity of prime factorization of large numbers from ~O(√N) to O(log(N)³), which means the tens of millions of years of computation time originally required to crack RSA encryption can be shortened to just a few days.
However, current quantum computing technology is still in a very early stage. Limitations in underlying fundamental physics cause qubits to easily decohere and lose their quantum entanglement properties, so the best record so far has only been able to factor 21 into 3 multiply by 7. But it's always good to plan ahead—many research teams have already begun studying new post-quantum cryptography techniques to safeguard future secure network communications.
Another Interesting Topic — Zero-Knowledge Proofs
Besides quantum computing, there's another interesting encryption technology called zero-knowledge proofs. Imagine if there was a special method to prove to a bank that I know the account password without entering the password in any way—in which case my password would be forever safe. Is this possible?
Yes, it is possible! Let's assume both the bank and you know what the real bank account password is, but neither party is willing to directly enter the password anywhere to prevent any possible leaks. So the bank asks this to you:
"Square your password, subtract 1248, multiply by 13, and finally take modulo 1107. What do you get?"
You do some calculation and answer: "247!"
The bank asks again:
"Calculate the factorial of the last two digits of your password, take the reciprocal, and tell me what the 67th digit after the decimal point is?"
You do some calculation and answer: "9!"
After repeating this process for 10 times, you answered all challenges correctly, so the bank believes you indeed know the password. Verification passed.
// Simplified zero-knowledge proof concept
interface Challenge {
operation: (password: string) => number;
description: string;
}
function zeroKnowledgeVerification(
realPassword: string,
claimedKnowledge: (challenge: Challenge) => number,
rounds: number = 10
): boolean {
const challenges: Challenge[] = generateRandomChallenges(rounds);
for (const challenge of challenges) {
const expectedResult = challenge.operation(realPassword);
const claimedResult = claimedKnowledge(challenge);
if (expectedResult !== claimedResult) {
return false; // Failed verification
}
}
// Probability of guessing correctly all rounds: (1/2)^rounds
return true; // Verification passed
}
That's right, this method cannot 100% guarantee that you definitely know the password, but the probability of an attacker answering correctly ten consecutive times approaches zero infinitely, so it can be considered safe from a computational perspective.
Andrew Yao, the 2000 Turing Award winner, once proposed the famous Millionaire's Problem, which used zero-knowledge proofs:
Two millionaires want to compare who has more money, but neither wants to reveal exactly how much money they have, nor do they want to trust any third party. So is there a way that allows them to know who has more money without knowing exactly how much the other has?
Do you know the answer?
