对使用公钥和私钥进行加密（用于加密）感到困惑
当客户向我的服务器索要许可证时，我正在制作一个许可证系统，如果他们被允许拥有许可证，我会向他们发送许可证。
在我当前的系统上，我使用单个私钥对许可证进行加密，并将公钥嵌入到用于解密许可证的客户端应用程序中。有用！
其他人告诉我，我应该使用服务器上的公钥进行加密，并将私钥分发给客户端。我在网上搜索了一下，发现有时他们使用私钥加密，有时他们使用公钥加密。
这种情况我该怎么办呢？
I am making a licensing system when clients ask my server for a license and I send them a license if they are permitted to have one.
On my current system I encrypt the license using a single private key and have the public key embedded into the client application that they use to decrypt the license. It works!
Others have told me that I should be encrypting with the public key on the server and distributing the private key to clients. I have searched the web and can see that sometimes they use the private key to encrypt and other times they use the public key to encrypt.
In this case what am I supposed to do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
恭喜，您刚刚发明了 RSA 签名。 （无论如何，这就是您应该使用的。）要与公钥系统通信，您需要使用一次私钥和一次公钥，但 RSA 支持两种不同的顺序：
1）用公钥加密，用私钥解密：接收者不知道消息的来源，但发送者知道只有接收者（私钥的持有者）可以读取它。这就是经典的“加密”。
2）用私钥“加密”，然后用公钥“解密”。这是一个数字签名，并提供身份验证。任何人都可以阅读该消息，但只有私钥持有者才能发送该消息。
假设您的许可证是针对客户端定制的（这可能就像包含客户端生成的随机数的副本一样简单），那么它对其他人来说毫无用处，但客户端可以确定服务器发送了它。
实际上，对称性并不是那么整齐。不同的操作模式有不同的弱点和陷阱，因此实施方式通常有很大不同，但这是总体思路。
密码学的第一个也是最重要的课程之一是了解身份验证以及何时使用它。它的使用频率至少与加密一样频繁，并且不知道何时使用它会让您陷入米德维尔天才学校情况。
Congratulations, you just invented the RSA signature. (Which is what you should be using, anyway.) To communicate with a public key system, you need to use the private key once and the public key once, but RSA supports two different orders:
1) Encrypt with the public key, decrypt with the private: The recipient doesn't know anything about the source of the message, but the sender knows that only the recipient (the holder of the private key) can read it. This is classical "encryption".
2) "Encrypt" with the private key, then "decrypt" with the public. This is a digital signature, and provides authentication. Anyone can read the message, but only the private key holder could have sent it.
Assuming your license is customized to the client (which could be as simple as including a copy of a client-generated random number), then it's useless to anyone else, but the client can be sure that the server sent it.
The symmetry isn't quite that neat in practice; the different modes of operation have different weaknesses and gotchas, so the implementation is typically significantly different, but that's the general idea.
One of the first and most important lessons in cryptology is understanding authentication and when to use it. It's needed at least as often as encryption, and not knowing when to use it leaves you in a Midvale School for the Gifted situation.
如果您要加密仅供单个收件人读取的内容，则您可以使用该收件人的公钥进行加密，而他们则使用其私钥来读取它。
如果您要为多个收件人加密，那么您可以使用私钥进行加密，并将公钥分发给您希望能够读取的人。这通常称为“签名”，因为有权访问您的公钥的任何人都可以读取它，因此这并不是真正的私人通信形式。
对您来说，一个整体更强大的解决方案是让您的应用程序在每次安装时生成一个密钥对，将其生成的公钥发送回服务器，然后您将使用该密钥进行加密，以便只有该单个安装才能使用该许可证您创建的（通过使用其私钥对其进行解密）。
If you are encrypting something that is only to be read by a single recipient, then you encrypt with that recipients public key and they use their private key to read it.
If you are encrypting for multiple recipients, then you can encrypt with your private key and distribute your public key to those which you want to be able to read it. This is usually called "signing" as anyone who has access to your public key can read it, so it's not really a form of private communication.
An overall more robust solution for you would be for your app to generate a key pair per installation, send the public key that it generated back to the server, which you would then use to encrypt so that only that single install could use the license that you created (by decrypting it with its private key).
至少在典型的公钥加密算法（例如，RSA）中，公钥和私钥之间并没有真正的重大区别。当你生成密钥时，你会得到两个密钥。您将其中一个保密并发布另一个，但发布哪一个以及将哪一个保密并不重要。
使用一个密钥加密的任何内容都可以使用另一个密钥解密。出于正常目的，您发布一个密钥，它可以让任何人加密只有您可以解密的内容。从技术角度来看，反之亦然：如果您使用私钥加密某些内容，则任何拥有公钥的人都可以解密它。这通常用于诸如签名验证之类的事情（即，任何拥有公钥的人都可以验证签名必须是使用私钥创建的）。不过，您通常希望使用单独的密钥对进行加密和签名。
就您的情况而言，您真正要实现的目标可能存在一些问题。您当然可以加密使用该程序所需的一些数据，因此用户需要密钥来解密它并使用该程序 - 但如果用户愿意将代码的副本提供给未经授权的人人，他们可能会毫不犹豫地给他们一份钥匙的副本。因此，即使加密/解密能够完成其工作，它也不太可能提供任何真正的保护。
更典型的许可方案与特定 IP 地址之类的内容相关联，因此您可以执行诸如加密 IP 地址之类的操作，然后使用结果作为密钥来解密使用该程序所需的数据。如果IP地址错误，数据就无法正确解密，程序也无法运行。只要用户拥有静态 IP 地址，这种方式就可以正常工作，但与 DHCP 结合使用时会出现问题。
我的直接建议是根本不要这样做。如果您坚持这样做，请不要自己这样做 - 获取类似 FlexNet 为您处理。没有它你会过得更好，但至少这样你会得到一些有点有用的东西，并且你不会在上面浪费时间和精力，而这些时间和精力可以用于更好的目的，例如改进你的软件。
At least in a typical public key encryption algorithm (e.g., RSA) there's not really a major difference between the public and the private key. When you generate keys, you get two keys. You keep one private and publish the other -- but it doesn't matter much which one you publish and which one you keep private.
Anything you encrypt with one key can be decrypted with the other key. For normal purposes, you publish one key, which lets anybody encrypt something that only you can decrypt. From a technical viewpoint, the reverse works fine though: if you encrypt something with your private key, anybody with the public key can decrypt it. This is typically used for things like signature verification (i.e., anybody with the public key can verify that the signature had to have been created with the private key). You usually want to use separate key pairs for encryption and signing though.
For your case, it's open to some question what you're really going to accomplish. You can certainly encrypt some data necessary to use the program, so the user needs the key to decrypt it and use the program -- but if the user is willing to give a copy of the code to an unauthorized person, they probably won't hesitate at giving a copy of the key to them as well. As such, even though the encryption/decryption will do it's job, it's unlikely to provide any real protection.
A more typical licensing scheme is tied to something like a specific IP address, so you do something like encrypting the IP address, then use the result as a key to decrypt data necessary to use the program. If the IP address is wrong, the data isn't decrypted correctly, and the program doesn't work. As long as the user has a static IP address this can work well -- but will cause problems in conjunction with DHCP.
My immediate advice would to just not do this at all. If you insist on doing it anyway, don't do it yourself -- get something like FlexNet to handle it for you. You're better off without it, but at least this way you'll get something that sort of works, and you won't waste time and effort on it that could be put to better purposes like improving your software.
如果您使用公私（非对称）加密，则始终使用收件人的公钥进行加密，收件人使用其私钥进行解密。对于数字签名，您使用私钥进行签名，接收者使用其公钥验证签名。
那么问题来了，如何制作一个安全的 DRM 系统？如果您使用加密，并为收件人提供私钥，他们可以分发密钥或解密的内容。如果您使用签名，他们可以简单地删除程序中的签名验证部分。
答案是不可能。 DRM 的概念从根本上来说是有缺陷的。
If you are using public-private (asymmetric) encryption, you always encrypt with the recipient's public key, who decrypts with their private key. For digital signatures, you sign with your private key and the recipient verifies the signature with their public key.
The question then arises, how do you make a secure DRM system? If you use encryption, and give the recipients a private key, they can distribute either the key or the decrypted content. If you use signatures, they can simply strip out the signature verification part of your program.
The answer is that it's impossible. The concept of DRM is fundamentally flawed.
希望维基百科的这个链接有帮助。 PKI 基于相互信任。然而，私钥必须由所有者保护。公共顾名思义是对所有人开放的。整个架构的建立是为了帮助您问题中上面定义的场景。
Hope this link from wikipedia helps. PKI is based on mutual trust. However the private key has to be protected by the owner. Public as the name implies is open to all. The entire architecture is made inorder to help the scenario as defined above in your question.
那些人错了。名称私钥意味着它是私有的，意味着只有您可以访问它。
使用数字签名。使用您的私钥对许可证文件进行签名，并在应用程序中使用您的公钥来验证许可证上的签名是否来自您。
Those people are wrong. The name private key implies that it is private meaning that only you should have access to it.
Use digital signatures. Sign the license file with your private key and use your public key in your application to verify that the signature on the license came from you.