In the previous post we established that secure license-key generation requires a digital signature scheme — never a shared symmetric secret embedded in the product binary.

That settles the security question. It immediately raises a usability one: which signature algorithm fits inside a license key short enough to type from a printed invoice?

This post walks through that decision in detail, contrasting RSA and elliptic- curve cryptography (ECC), and explains why every modern licensing SDK that takes both security and UX seriously ends up on ECC.

Recap: what we are signing, and what we are sending

A license key, broken down to its essentials, is a tuple:

KEY = KEY_DATA | SIGNATURE(KEY_DATA)

Where KEY_DATA carries the bits the product needs to know — edition, seat count, expiry, customer id — and SIGNATURE(KEY_DATA) is what proves the publisher generated it.

Both pieces have to be encoded into a typeable string, almost always Base32 (5 bits per character, with confusing characters like O, 0, I, 1 removed). Total key length in characters is therefore ceil((data_bits + signature_bits) / 5).

The signature is the dominant term by far.

Trying RSA first

RSA is the digital-signature algorithm most developers learned in school. It is well-understood, has excellent library support, and the security analysis is mature. So let's see what an RSA-signed license key would actually look like.

The current public recommendation for new RSA deployments is a 2048-bit modulus (1024-bit is considered broken; 3072-bit is recommended for long-lived data). A 2048-bit RSA signature is exactly 256 bytes — that is the modulus size, by definition.

Encoded in Base32, 256 bytes becomes:

ceil(256 * 8 / 5) = 410 characters

For just the signature. Add even a tiny 8-byte payload and you are at 422 characters, formatted into 84 groups of 5. No human will type that. No support agent will read it over the phone. No reseller will fit it on a postcard.

You can shave a little off with truncated hashes (which weaken the scheme) or deterministic ECDSA-on-RSA hybrids (which do not exist). The fundamental issue is the modulus size, and it is not negotiable for security reasons.

This is why the few products that try to use RSA for licensing fall back to license files instead of license keys — a binary blob you double-click, or a multi-line Base64 dump you paste into a textbox. License files solve the size problem, but they introduce their own usability disasters: you cannot read them over the phone for activation; resellers cannot include them on a sticker or printed certificate; "I lost my license file" becomes a daily support ticket; and refunds spike.

ECC: equivalent strength, a fraction of the bytes

Elliptic-curve cryptography produces digital signatures that are cryptographically equivalent to much larger RSA signatures. The widely-cited NIST equivalence table:

Symmetric strength	RSA modulus	ECC field size
80 bits	1024 bits	160 bits
112 bits	2048 bits	224 bits
128 bits	3072 bits	256 bits
192 bits	7680 bits	384 bits

Read the third row carefully: a 256-bit ECC key gives the same security as a 3072-bit RSA key — 12× smaller, with the security level current guidance recommends for newly-deployed cryptography.

For signature size, the typical Schnorr-family ECC signature is roughly 2 × field_size bits. A 160-bit curve produces a ~40-byte signature. That is 64 Base32 characters. Drop in a small payload, format into groups of 5, and you are looking at a 25-30 character key — exactly what users expect.

The Schnorr twist that keeps keys distinct

There is a subtler reason ECC (specifically Schnorr-style signatures over ECC) wins for licensing — one that is rarely discussed but matters a lot in practice.

Most signature schemes are deterministic: same input, same key, same signature. That is a problem for license keys, because two customers who happen to buy the same product edition on the same day would receive identical keys. To avoid this, deterministic schemes have to either:

• Add a random salt to the payload (which inflates the data portion), or
• Add a customer-specific field like email or order id (which ties the key to per-customer data and complicates reseller workflows).

Schnorr signatures, by contrast, are non-deterministic by design: the signing process picks a random nonce, and there are exponentially many valid signatures for the same payload under the same private key. Two customers buying identical SKUs get different keys, and the data portion stays minimal.

This single property is the reason a SoftActivate-style key can carry only a few bytes of payload (edition + flags) and still be unique per customer.

The patent landscape (briefly)

ECC has a famously thorny patent history. Most of it is now expired or never applied to the variants used in licensing. The combination this SDK uses — ECC over GF(2^n) with a polynomial basis representation, signed with Schnorr (whose key patent expired in 2008) — is unencumbered by Certicom's historical claims.

Curves over prime fields (the kind used by ECDSA, EdDSA, secp256k1) are similarly free of active patents at this point. If you are evaluating licensing libraries, "uses ECC" is no longer a red flag the way it was in the early 2000s.

A worked example

Here is what a real ECC-signed license key looks like, broken down:

KEY:  M9Y2P-K3HFQ-X7TBR-NCAS4-VGW8E-J5DUZ
            └─ 30 chars × 5 bits = 150 bits total
            ├─ 10 bits payload (edition, flags)
            └─ 140 bits Schnorr signature over GF(2^160)

The customer types 30 characters. The product runs ~5 ms of ECC verification on first launch, caches the result, and never bothers them again. Cryptographically, an attacker would need to forge a Schnorr signature over GF(2^160) without the private key — currently estimated at ~2^80 operations, which is computationally infeasible. The product binary contains only the public verification key. Even a perfect reverse-engineering of the binary yields no ability to mint new keys.

That is the entire point of using public-key cryptography for licensing.

Bottom line

Property	RSA-2048	ECC + Schnorr (160-bit)
Equivalent symmetric strength	112 bits	80 bits
Signature size	256 bytes	~20 bytes
Key length in Base32	410+ chars	25-30 chars
Distinct keys for same SKU	requires salt	free (Schnorr nonce)
Suitable for typeable keys	No	Yes
Suitable for license files	Yes (clunky UX)	Yes (overkill)

If you want typeable, secure, per-customer-distinct license keys, ECC with a Schnorr-family signature scheme is not just a good choice — it is effectively the only viable choice. RSA is fine if you are willing to live with license files; for everyone else, ECC wins on every axis that matters.

For the full design context — hardware fingerprinting, activation servers, expiring licenses — see the pillar guide: How To Generate License Keys Securely.

The SoftActivate Licensing SDK ships an ECC-over-GF(2^n) + Schnorr implementation with full C++ and C#/.NET source code, so you can read every line of the verification routine that ends up inside your shipped binary — which is, incidentally, exactly the level of transparency you want from anything guarding your revenue.