A license key algorithm turns a secret you hold into a key that others can verify but not forge. That is the whole job. The reason so many license systems get cracked is that they use algorithms which put the verification logic — and sometimes the secret itself — inside the app they ship. Once that logic is on the users machine, someone can read it and build a key generator. The fix is to verify with a digital signature, where the secret never leaves your server.
What a license key algorithm does
At its core, a key algorithm has two halves: generation, which produces a key, and verification, which decides whether a key is genuine. The security of the whole scheme depends on one question: can an attacker who sees your verification code also generate valid keys? If the answer is yes, you have a keygen problem. If the answer is no, you are in good shape.
The old way: partial key verification
For years, a popular approach was partial key verification. The key was split into many small pieces, and each release of the software only checked a handful of them. The theory was that a cracker who reversed one version would only learn how to fake part of the key, so you could change which pieces you checked in the next release and invalidate their keygen.
Why partial key verification is broken
The theory does not survive contact with reality. All the checking logic still lives inside the app, so a determined cracker reverses the generation scheme, not just the checks, and produces keys that pass every version. Partial key verification raises the effort slightly and buys a little time, but it is security by obscurity. Once the algorithm is understood, it is over.
The modern way: digital signatures
The robust approach flips the problem. Instead of hiding the checking logic, you make forgery mathematically hard. You sign each key, or each validation response, with a private key that lives only on your server. The app verifies that signature. Because verifying does not reveal how to sign, a cracker who fully reads your app still cannot produce a valid key. This is the same idea that makes server-side license validation trustworthy.
Symmetric (HMAC) versus public-key (Ed25519)
There are two families of signatures, and the difference matters.
- HMAC uses a single shared secret for both signing and verifying. It is simple and fast, but anything that can verify can also sign — so the secret cannot ship inside your app. HMAC is fine when verification happens on your server.
- Public-key signing, such as Ed25519, uses a private key to sign and a separate public key to verify. The app can safely carry the public key, because it cannot be used to forge anything. This is what you want when verification has to happen inside a distributed app.
What to use today
For a product you sell: never invent your own algorithm, and never trust an unsigned key. Use Ed25519 signatures if the app must verify locally, or server-side validation with signed responses if it can call home. Both keep the signing secret off the users machine, which is the one property that actually stops keygens. If you want to see it in practice, our post on generating a license key in Python walks through the code.
Want signed keys and signed validation without building the crypto yourself? Get started free.
Frequently asked questions
How do license keys work?
A license key encodes proof that you issued it. When the software runs, it checks that proof — either by verifying a cryptographic signature on the key or by asking your server whether the key is genuine. A key with no verifiable proof behind it can be faked by anyone.
What is partial key verification?
Partial key verification is an older scheme where each release of the software only checks a few characters of the key. The idea was to limit how much a keygen author could learn from one cracked version. In practice the checking logic lives in the app, so it can be read and reversed.
Are license key algorithms secure?
Many classic algorithms are not, because they put the verification logic inside the app you ship, where a cracker can read it and build a keygen. A secure algorithm uses a digital signature that the app can verify but not forge, because the signing secret stays on your server.
What is the difference between HMAC and public-key signing?
HMAC uses one shared secret to both sign and verify, so anything that can verify can also forge — which means the secret cannot ship in the app. Public-key signing, such as Ed25519, uses a private key to sign and a separate public key to verify, so the app can safely carry the public key without being able to forge keys.
Should I write my own license key algorithm?
For anything you sell, no. Key generation is easy to get wrong in ways that only show up after someone builds a keygen. Use a vetted signing library or a licensing service, and keep the signing secret on a server.