Alex: The SHA-1 is just an example payload here, not very essential, i.e. I would suggest (also) including a serial number (32 bit integer) to uniquely identify the key rather than rely on the hash to be the only unique identifier (as people/companies/IT departments do request name changes).

Which is something those of you wanting a short key should consider, simply providing an encrypted hash is not ideal as at least I include the following info in the license key: Serial number, date issued, number of seats (for site licenses), type of license (academic license, evaluation/NFR, gift, etc.), and maybe a few other things.

But ECDSA can still work for this requirement e.g. by prefixing the signature with this info (compacted into a long integer) but remember to also have the actual signature be on this data, so that altering this prefix invalidates the key.

[1][http://www.schneier.com/crypto-gram-0901.html#3]

Did anyone ever try to use Elliptic Curve Cryptography (http://en.wikipedia.org/wiki/Elliptic_curve_cryptography) instead of RSA for this? Supposedly one can use smaller key lengths with similar security, which could result in shorter license keys. Crypto++ (http://www.cryptopp.com) is a crypto-library supporting ECC.

assert(data_size == RSA_size(rsa_key));

If you meant data_size to be the length of the unencoded message, then the assertion is correct, but data_size is not the length of the encoded message, so it is the incorrect argument to pass to RSA_public_decrypt. In this case you would pass data_size + 11 to RSA_public_decrypt.

I think your post would benefit from a more complete working example because there are a few things that are not obvious, like this issue with padding, the format of the public key, etc. Also, you never free the memory pointed to by dst.

Marc

Exactly. That would be a horribly misleading article if it wasn't generally understood that no matter how secure a door lock is, a robber can break in the windshield. An article that claimed to provide a car security policy that only talked about secure door locks would be very misleading.

Specifically, the articles says, "… in a way which should make it difficult for the cracker to generate his own fake license key(s)." This is true in a very technical sense — they cannot create fake license keys that will be accepted by the unmodified software. It is not, however, true in the more important practical sense, there is no assurance they cannot run the software without a valid license.

As for a disclaimer clearing up the confusion, I don't think that's needed. I think the comments have cleared up the misunderstandings. It might be helpful to put somewhere something like: "Generating licenses that are difficult to forge is only one part in a licensing scheme. No matter how difficult it is to generate a fake license that will be accepted by the unmodified software, one can modify the software to accept an invalid license. Defeating such attempts is outside the scope of the license generation scheme."

You didn’t address my suggestion of putting in a disclaimer to help with the confusion you say you have observed, how about being constructive for a change?