加密产品密钥：公钥和私钥加密
我需要生成和验证产品密钥，并且一直在考虑使用公钥/私钥系统。
我根据
- 客户名称（可以是可变长度字符串）和
- 6 位序列号生成产品密钥。
如果产品密钥的长度是可管理的（16 个字符左右），那就太好了，
我需要在基础上对它们进行加密，然后分发解密/验证系统。由于我们的系统是用托管代码（.NET）编写的，因此我们不想分发加密系统，而只想分发解密。我需要一个公共私钥似乎是执行此操作的好方法，使用我保留的一个密钥进行加密并分发解密/验证所需的另一个密钥。
满足上述要求的适当机制是什么？
注意：这并不是为了阻止盗版；而是为了阻止盗版。这是为了减少新手用户安装他们不需要/未经授权使用的组件的可能性。
I need to generate and validate product keys and have been thinking about using a public/private key system.
I generate our product keys based on
- a client name (which could be a variable length string)
- a 6 digit serial number.
It would be good if the product key would be of a manageable length (16 characters or so)
I need to encrypt them at the base and then distrubute the decryption/validation system. As our system is written in managed code (.NET) we dont want to distribute the encryption system, only the decryption. I need a public private key seems a good way to do this, encrypt with the one key that i keep and distribute the other key needed for decrpytion/verification.
What is an appropriate mechanism to do this with the above requirements?
NOTE: It's not to stop piracy; it's to reduce the likelyhood of novice users installing components they dont need/unauthorised to use.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
.NET 支持多种方式的公钥加密，例如 http://msdn。 microsoft.com/en-us/library/ms867080.aspx。话虽如此，您所获得的只是一些信心，即拥有已发布代码的完全访问权限的人将无法颁发自己的产品密钥。这些都不能阻止他们修补客户端以接受任何东西作为有效密钥。这就是混淆的用武之地。
.NET supports public key encryption in various ways, such as http://msdn.microsoft.com/en-us/library/ms867080.aspx. Having said this, all you'd gain is some confidence that someone with full access to the released code would not have the ability to issue their own product keys. None of this stops them from patching the client to accept anything as a valid key. That's where obfuscation fits in.
甚至不要试图花哨反盗版。这是不值得的。我已经破解了无数的应用程序（嘘），而 .NET 的应用程序是迄今为止最简单的。但实际上，只要有足够的经验，它们都相对容易。如果你不相信我，找时间看看 isohunt。
tl;dr：这是一场失败的战斗。不要对抗它。如果你真的想赢，就起诉侵权行为——但即使这样你也会输。
Don't even try to get fancy with anti-piracy. It's not worth it. I've cracked countless applications (hush) and .NET ones are by FAR the easiest. But in reality, they're all relatively easy with enough experience. If you don't believe me, check out isohunt some time.
tl;dr: It's a losing battle. Don't fight it. If you really want to win, sue infringments - but even that makes you lose.
我做了一些非常相似的事情。但就我而言，这是一个简单的电话授权码。用户可以拨打一个号码，提供他们的公司名称和他们正在执行的操作，获取代码，将其输入到应用程序中，然后就可以继续。
我所做的是将一段数据序列化为二进制。这些数据包括经过哈希处理的公司名称、操作代码/到期日期，并且有足够的空间以满足未来的需求。然后我将这些位分散在阵列周围以混淆它。然后，我将二进制数组的每 5 位映射到 32 个字符的验证码字母表（0-9、az，不包括 I/O/Q/S，以便通过电话读取）。
这产生了一个很好的授权代码，它有 16 个字符，显示为 4x4 块 (####-####-####-####)。它可以很容易地通过电话读出，因为用户一次只需听四个字符，甚至可以通过短信发送。
与您的问题一样，它并不是为了阻止 Bletchley Park 的代码破解者，但是足以阻止普通上班族做一些不遵守公司程序的事情。而且，考虑到这个范围，它非常有效。
I did something very similar. But in my case it was a simple telephone authorisation code. User would phone a number, give their company name and the operation they were performing, get a code, type it into the application and then be able to proceed.
What I did was serialise a piece of data into binary. The data included the hashed company name, operation code/expiration date, and had space to spare for future requirements. I then scattered the bits around the array to confuse it. Then I mapped each 5 bits of the binary array onto a 32 character auth-code alphabet (0-9,a-z,excluding I/O/Q/S for readability over telephone).
This resulted in a nice auth-code which was 16 characters, displayed as 4x4 blocks (####-####-####-####). It could be easily read out over the telephone, as the user only had to listen to four characters at a time, or even sent via SMS.
As with your problem, it wasn't intended to stop the code crackers at Bletchley Park, but was enough to stop the average office worker from doing something without following company procedure. And, given that scope, has been very effective.