请查看关于部分密钥验证的文章，其中包括以下要求:

License keys must be easy enough to type in. We must be able to blacklist (revoke) a license key in the case of chargebacks or purchases with stolen credit cards. No “phoning home” to test keys. Although this practice is becoming more and more prevalent, I still do not appreciate it as a user, so will not ask my users to put up with it. It should not be possible for a cracker to disassemble our released application and produce a working “keygen” from it. This means that our application will not fully test a key for verification. Only some of the key is to be tested. Further, each release of the application should test a different portion of the key, so that a phony key based on an earlier release will not work on a later release of our software. Important: it should not be possible for a legitimate user to accidentally type in an invalid key that will appear to work but fail on a future version due to a typographical error.

所有的CD拷贝保护算法给诚实的用户带来不便，同时没有提供任何防止盗版的保护。

“盗版者”只需要获得一张合法的cd及其访问代码，他就可以制作n份拷贝并分发它们。

无论代码的加密安全性如何，都需要以明文形式提供CD，否则合法用户无法激活该软件。

Most secure schemes involve either the user providing the software supplier with some details of the machine which will run the software (cpu serial numbers, mac addresses, Ip address etc.), or, require online access to register the software on the suppliers website and in return receive an activitation token. The first option requires a lot of manual administration and is only worth it for very high value software, the, second option can be spoofed and is absolutly infuriating if you have limited network access or you are stuck behind a firewall.

总的来说，与客户建立信任关系要容易得多!

还有一些DRM行为将多个步骤合并到流程中。最著名的例子之一是Adobe验证其Creative Suite安装的方法之一。使用这里讨论的传统CD Key方法，然后调用Adobe的支持线。CD密钥将提供给Adobe代表，他们将返回用户使用的激活号码。

然而，尽管被分成了几个步骤，但这与正常过程中使用的破解方法相同。人们很快发现了用于创建与原始CD密钥进行检查的激活密钥的过程，并制作了包含这两个密钥的生成器。

然而，这种方法仍然作为一种没有互联网连接的用户验证产品的方式存在。展望未来，随着互联网接入变得无处不在，很容易看到这些方法将被淘汰。

如果您不是特别关心密钥的长度，那么使用公钥和私钥加密是一种行之有效的方法。

本质上有某种临时的和固定的签名。

例如: 0001 - 123456789

其中0001是您的临时签名，123456789是您的固定签名。

然后用你的私钥加密，得到你的CD密钥，就像这样: ABCDEF9876543210

然后在应用程序中分发公钥。公钥可用于解密CD密钥“ABCDEF9876543210”，然后验证其固定签名部分。

这可以防止某人猜测nonce 0002的CD密钥是什么，因为他们没有私钥。

唯一的主要缺点是，当使用1024位的私有/公共密钥时，您的CD密钥将非常长。您还需要选择一个足够长的nonce，这样您就不会加密少量的信息。

好的一面是，这种方法不需要“激活”就可以工作，你可以使用电子邮件地址或被许可方的名称作为临时标识。

请查看关于部分密钥验证的文章，其中包括以下要求:

License keys must be easy enough to type in. We must be able to blacklist (revoke) a license key in the case of chargebacks or purchases with stolen credit cards. No “phoning home” to test keys. Although this practice is becoming more and more prevalent, I still do not appreciate it as a user, so will not ask my users to put up with it. It should not be possible for a cracker to disassemble our released application and produce a working “keygen” from it. This means that our application will not fully test a key for verification. Only some of the key is to be tested. Further, each release of the application should test a different portion of the key, so that a phony key based on an earlier release will not work on a later release of our software. Important: it should not be possible for a legitimate user to accidentally type in an invalid key that will appear to work but fail on a future version due to a typographical error.

我对人们如何生成CD密钥没有任何经验，但是(假设你不想走在线激活的道路)这里有一些方法可以生成密钥:

Require that the number be divisible by (say) 17. Trivial to guess, if you have access to many keys, but the majority of potential strings will be invalid. Similar would be requiring that the checksum of the key match a known value. Require that the first half of the key, when concatenated with a known value, hashes down to the second half of the key. Better, but the program still contains all the information needed to generate keys as well as to validate them. Generate keys by encrypting (with a private key) a known value + nonce. This can be verified by decrypting using the corresponding public key and verifying the known value. The program now has enough information to verify the key without being able to generate keys.

这些漏洞仍然容易受到攻击:程序仍然存在，可以通过打补丁绕过检查。更聪明的方法可能是使用第三个方法的已知值加密部分程序，而不是将值存储在程序中。这样，在解密程序之前，你必须找到密钥的副本，但一旦解密，它仍然很容易被复制，并且有一个人拿着他们的合法副本，并使用它使其他人能够访问软件。