Question

I’m implementing a small application in C, which I would like to sell as shareware for a reasonable price later on. It will start of with a 30-day trial, which I am already quite certain of how to implement it.

The problem I have, though, is that I am not quite sure how to implement the product key verification. What I have in mind is that the customer can sign up on my webpage (after trying the product for a while), pay for the product, and get a product key in the form of aaaaa-bbbbb-ccccc-ddddd-eeeee via e-mail (or maybe available via his profile on my website). No problem so far. He/She then drops the key in the appropriate key fields in my app and boom the app is registered.

From what I could gather so far, people either recommend AES or RSA for this. To be honest, I in another direction in college (not cryptography) and the one cryptography class I took was some time ago. But from what I remember, AES is a symmetric encryption algorithm, which would mean that I would only have one key for encryption and decryption, right? How could I then generate thousands of product keys and still validate them in my app (which by the way won’t require internet access….so no checking back with a server)?

So I guess RSA would be the way to go? But doesn’t RSA produce pretty long keys (at least longer than the required 25 characters from above)?

In another thread I read that some products won’t even use encryption for the product key generation/verification, but instead just employ some checks like ‘add the 2. and the 17. character and that should total to x’.

What’s the fastest, easiest and most secure way to go here? 🙂 Code samples would be sugar!

Regards,

Sebastian

P.S.: Oh…and please don’t tell me how my key can and will be cracked at some point…..I know about that, which is primarily why I don’t want to spend a lot of time with this issue, but at the same time not make it too easy for the occasional cracker.

Answer 1

Symmetric algorithms are limited, in that any novice cracker with a disassembler can find your key (or the algorithm used to generate one) and make a ‘keygen’.

For this reason, asymmetric cryptology is the way to go. The basic premise is something like this:

• When the user purchases a license from you, you collect certain identifying details about the user and/or their environment (typically, this is just a full name; sometimes a company, too).
• You make a 128-bit MD5 hash of this information.
• Using a 128-bit Elliptic Curve crypto, encrypt this hash using the private key on the server.
• The 128-bit cipher text can be represented to the user as a 25-character string consisting of letters and digits (plus separating dashes for readability). Notice that 26 letters + 10 digits = 36 discrete values, and that 36^25 > 2^128.
• The user types this product key into your registration dialog. The client software converts it back to a 128-bit number (16 bytes), decrypts that using the public key of your EC crypto, and compares the result to an MD5 hash of the user’s personal information, which must match what was used for registration.

This is just the basic idea, of course. For more details and source code, see Product Keys Based on Elliptic Curve Cryptography.