implementation for product keys [closed]

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.

Answer 2

Life is simpler if you simply purchase a solution.

http://www.kagi.com/kagisolutions/index.php

Kagi allows you to collect payments and they help you manage the keys.

Answer 3

You can check out this Code Project article. It describes an implementation of a a software key based on the MAC address of the machine where the software is executed. The method is not ideal, as the auteur himself admits, and it is a little bit different from what you are looking for, but maybe it can help you.

Answer 4

Yes, RSA and AES are two very different things:

• RSA is public key cryptography, involving a public key and a private key, and is fairly slow. The primary use is to set up a secure exchange of a symmetric encryption session key.
• AES is symmetric encryption, which is fast and secure.

Since your app does not communicate over public channels and the use of cryptography is limited to product activation/registration you'll want to go with a symmetric cipher. The benefits of public key ciphers is in key management, which you will be handling on your web site or through email.

Note that you do not have to distribute the same key for every customer. You could generate a hash of some of the registration info and XOR it with something else (a fixed session key, perhaps). Send that to the customer, and the program could generate the same hash and XOR will the key you sent to produce the original fixed key.

Dealing with cryptography is not something to be done lightly. As you mention, you expect this to be cracked. If you're doing your own this will almost certainly happen. You can still use your own implementation to "keep honest people honest," but realize that's as far as you'll get. If you need something stronger then you should purchase a solution after doing thorough research on the solutions.

Answer 5

A guy has blogged about how he handled the question of registration numbers. One of his blog entries is Generating Unique Registration Numbers.