我可以使用带有两个私钥的非对称加密吗？
根据维基百科（和其他来源），非对称加密总是这样工作：
- 甲方有公钥和私钥
- 乙方用甲方的公钥加密内容
- 甲方用其私钥解密内容
但是，我不希望甲方能够加密他们自己的数据，并且只希望他们能够解密它。使用非对称逻辑，这将导致：
- 甲方有一个私钥
- 乙方有一个私钥（这是甲方的公钥）
- 乙方用他们的私钥加密东西
- 甲方用他们的私钥解密东西
我们将使用这个用于某种许可证生成/检查。我们的客户可能不会生成许可证，但许可证文件必须在客户端可读。
这仍然是非对称加密还是我应该考虑不同的方法？
According to wikipedia (and other sources), asymmetric encryption always works like this:
- Party A has a public and private key
- Party B encrypts stuff with A's public key
- Party A decrypts stuff with their private key
However, I don't want party A to be able to encrypt their own data and only want to them to be able to decrypt it. Using the asymmetric logic this would result in:
- Party A has a private key
- Party B has a private key (which is party A's public key)
- Party B encrypts stuff with their private key
- Party A decrypts stuff with their private key
We will be using this for some sort of license generation/checking. Our clients may not generate a license, but the license file must be readable on the client side.
Is this still asymmetric encryption or should I be looking at different methods?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
您将私钥放在保险箱中，并发布您的公钥。当您创建许可证时，您可以使用您的私钥对其进行加密。客户端只能使用您的公钥对其进行解密。
如果您想将许可证限制给某个客户端，请要求该客户端生成其密钥对，并将其公钥发送给您。然后，您使用他们的公钥加密许可证，然后使用您的私钥对其进行签名（或再次加密）。
当客户收到许可证时，他们必须
1. 验证您发送给他们的许可证的签名（或解密）
2. 使用自己的私钥解密验证后的数据。
这确保了 1. 只有您可以向他们发送许可证，2. 只有他们可以解密。
You have your private key in the safe, and publish your public key. When you create a license you encrypt it with your private key. The client can only decrypt it with your public key.
If you want to restrict your license to a client, ask the client to generate their keypair, and send their public key to you. You then encrypt the license with their public key, then sign it (or encrypt it again) with your private key.
When the client receives the license they will have to
1. verify the signature of (or decrypt) the license you sent them
2. decrypt the verified data using their own private key.
This ensures that 1. only you can send them the license and 2. only they can decrypt it.
您通常要做的就是在您这边生成许可证，并使用您的私钥对其进行加密。然后您的客户可以使用您的公钥读取它。 （非常广泛地讲）这就是证书方案（例如在使用 HTTPS 进行安全在线浏览时使用的）的工作原理。是的，这仍然绝对算作非对称加密。
What you'd generally do is generate you license on your side, and encrypt it with your private key. Then your client can read it using your public key. This is (very broadly speaking) how certificate schemes (such as used in secure online browsing with HTTPS) work. And yes, that still absolutely counts as asymmetric encryption.
根据您的说法，非对称加密仍然是您想要的，只是需要以与您习惯的方式不同的方式来完成。
假设您为 A 生成了一个密钥对。您将密钥对的一半发送给 A：这并不重要，但我们将其称为私有一半。您使用公共部分加密并将其发送给 A。然后 A 可以解密它。但是 A 将无法加密看似来自 A 公钥的消息，因为他们只有密钥的私有一半，并且如果您只有密钥的一半，则无法计算出密钥的另一半，无论你有哪一半。因此，A 只能加密可以通过您保密的公钥解密的消息。
当然，正如其他发帖者已经说过的，有更好的方法来设置这个协议。只要您了解非对称加密的细节并了解我们所说的密钥半部分以及我们通常如何使用它们，就可以解释为什么这并不是一个真正的问题。
Based on what you're saying, asymmetric encryption is still what you want, it just needs to be done in a different way than you're used to thinking about it.
Let's say you generate a key pair for A. You send A one half of the pair: it doesn't really matter but we'll call it the private half. You encrypt using the public half and send it on to A. Then A can decrypt it. But A won't be able to encrypt a message that appears to come from the A public key since they only have the private half of the key and you can't figure out the other half of the key if you only have half of it, no matter which half you have. So A could only encrypt messages that could be decrypted by the public key that you have kept as a secret.
Of course, as other posters have already said, there are better ways to set up this protocol. Just trying to explain why this is not really an issue once you understand the details of asymmetric encryption and look past what we like to call the key halves and how we usually use them.
您可以查看 Rhino 许可： http://hibernatingrhinos.com/open-source/犀牛许可/介绍
You could have a look at Rhino licensing : http://hibernatingrhinos.com/open-source/rhino-licensing/introduction
其他答案已经说了如何做到这一点...这里只是注意一下（至少对于 RSA）您在问题中描述的方案是不安全的，如果它依赖于 B 的密钥保密。
对于 RSA，公钥和私钥实际上是不对称的，您不能简单地交换它们并期望获得相同的安全属性。
我认为其他非对称密码系统也存在类似的警告 - 始终仅按照指定和经过验证的方式使用它们。
在这种情况下，您将组合两个密钥对：B 的一对用于签名/验证消息（以确保消息是由 B 发送的），A 的一对用于加密/解密消息（以确保只有 A 可以读取它） 。
The other answers already said how to do it ... here just a note that (at least with RSA) the scheme you described in your question is not secure, if it depends on B's key staying secret.
For RSA, the public and private keys are really asymmetric, and you can't simply swap them and expect the same security properties.
I suppose similar caveats are there for other asymmetric cryptosystems - always use them only like they are specified, and proven.
In this case, you would combine two key pairs: B's one to sign/verify the message (to make sure the message was sent by B), and A's one to encrypt/decrypt the message (to make sure only A can read it).
是的。您可以使用 RSA 来实现 - 进行类似 Diffie-Hellman 的交换，因为不仅来自 1 个关联对的密钥可以交换，来自不同密钥对的密钥也可以交换。
<代码>
爱丽丝->鲍勃：爱丽丝.pub
鲍勃->爱丽丝：鲍勃.pub
爱丽丝： r = random.secret()
爱丽丝->鲍勃：( r * (alice.priv * bob.pub) )
鲍勃： r = ( (r * (alice.priv * bob.pub)) * (bob.priv * alice.pub) )
请注意，我们在这里做了一些奇怪的事情。我们将不同密钥对的 RSA 操作混合在一个操作中。括号中的对象实际上是一个新的虚拟 RSA 密钥，并且这些密钥都不是公开的。如果我们尝试直接创建 RSA 密钥，那么 alice 或 bob 都会知道该对的两个密钥。该密钥对实际上是一个秘密密钥，您向一端写入，只有另一方可以解密它，但您无法解密自己编写的内容，并且其他人都无法加密发送给另一方的消息。
我从未见过有人像这样混合密钥对，但我通过编写代码对此进行了测试。不过，我必须做一些不寻常的事情，因为通常，将私钥应用于消息是为了“签名”。但签名通常会对秘密进行哈希处理，并将私钥应用于其哈希；我们不想要的东西。因此，在我的代码中，一旦我将 RSA 组件（D、E、N）提取为任意精度数字...即：解密、加密、取模...我就这样做了：
虫洞发送（我，你，消息）=
(((me ^ {me_D}) \% me_N) ^ {you_E}) \% you_N
有点棘手的是，E（加密指数）实际上是一个可预测的值，但模数 N 位于公钥 (E,N) 中。 D 对各方都是私有的。我们在这里需要小心，因为你和我的模数 N 不同。
我这样做是因为我想要一个程序被授权加密用户可以解密的密钥的系统。这样做，用户无法加密密钥，程序也无法解密它们。
Yes. You can do it with RSA - to do a Diffie-Hellman-like exchange, because not only do the keys from 1 associated pair commute, but keys from different keypairs can commute as well.
alice -> bob: alice.pub
bob -> alice: bob.pub
alice: r = random.secret()
alice -> bob: ( r * (alice.priv * bob.pub) )
bob: r = ( (r * (alice.priv * bob.pub)) * (bob.priv * alice.pub) )
Notice that we did something odd here. We mixed RSA operations from different keypairs in one operation. The objects in parenthesis are effectively a new virtual RSA key, and neither one of these keys is public. Had we tried to create that RSA key directly, either alice or bob would know both keys of the pair. This keypair is effectively a secret key where you write to one end and only the other side can decrypt it, yet you cant decrypt what you wrote yourself, and nobody else can encrypt messages to the other side.
I have never seen anyone mix keypairs like this, but I tested this by writing the code. I had to do something unusual though because normally, applying the private key to the message is for 'signing'. But signing usually hashes the secret and applies the private key to a hash of it; something we do not want. So in my code, once I had the RSA components (D,E,N) extracted into arbitrary precision numbers... ie: decrypt,encrypt,modulus ... I just did:
wormholeSend(me,you,msg) =
(((me ^ {me_D}) \% me_N) ^ {you_E}) \% you_N
The thing that makes it a little tricky is that E (encrypt exponent) is actually a predictable value, but the modulus N is in the public key (E,N). D is private to each party. We need to be careful here, because you and I have a different modulus N.
I did this because I wanted a system where a program is authorized to encrypt keys that can be decrypted by users. Doing this, the user cannot encrypt keys, and the program cannot decrypt them.
甲方能够使用公钥加密消息绝对没有问题。
只有您可以解密它们（使用您的私钥），并且由于您没有理由这样做，因此使用应用程序中嵌入的公钥加密某些内容不会造成任何损害 - 只是用户拥有一堆无用的数据，因为他无法解密它。
对于许可，您只需使用您的私钥加密（或签名 - 这就足够了，然后人们将能够读取许可证文件中的限制等，但不能修改它们）您的许可证文件。然后，应用程序使用嵌入的公钥解密文件（或验证签名）。
提取公钥并用它签署自定义许可证文件的用户无法使用它，因为它只有在您的私钥嵌入到应用程序中时才有效（因为这是解密使用公钥加密的内容所必需的密钥）。
但是，他很可能用自定义密钥替换您的公钥（他也有私钥），然后使用他的私钥签署/加密他自己的许可证文件。但这不是一个加密问题 - 您只需添加一些防破解/修改措施，以使其更难替换嵌入的公钥。例如，您可以进行一些校验和验证。
Party A being able to encrypt messages using the public key is absolutely no problem.
Only you could decrypt them (with your private key) and since you have no reason to do so encrypting something with the public key embedded in your application would cause no harm - just a bunch of useless data the user has since he cannot decrypt it.
For the licensing you simply encrypt (or sign - that's enough and then people will be able to read the restrictions etc in the license file but not modidy them) your license file using your private key. The application then decrypts the file using the embedded public key (or validates the signature).
A user extracting the public key and signing a custom license file with it could not use it since it would only work if your private key was embedded in the application (since that's the key necessary to decrypt something encrypted with the public key).
However, he could very well replace your public key with a custom one (where he has the private key, too) and then sign/encrypt his own license file using his private key. That's not a cryptographical issue though - you simply need to add some anti-cracking/modification measures to make it harder to replace the embedded public key. You could do some checksum validations for example.