我可以使用带有两个私钥的非对称加密吗？答案

【问题标题】：Can I use asymmetric encryption with two private keys?我可以使用带有两个私钥的非对称加密吗？
【发布时间】：2011-08-05 11:39:32
【问题描述】：

根据维基百科（和其他来源），非对称加密总是这样工作：

甲方拥有公钥和私钥
B 方使用 A 的公钥加密内容
甲方使用其私钥解密资料

但是，我不希望甲方能够加密他们自己的数据，只希望他们能够解密它。使用非对称逻辑会导致：

甲方有私钥
乙方有一个私钥（即甲方的公钥）
B 方使用其私钥加密内容
甲方使用其私钥解密资料

我们将使用它来进行某种许可生成/检查。我们的客户可能不会生成许可证，但许可证文件必须在客户端可读。

这仍然是非对称加密还是我应该寻找不同的方法？

【问题讨论】：

B 的 private 密钥如何也是 A 的 public 密钥？根据定义，两者是相互排斥的。私密的内容应该保密，而不是公开。
这有点难以解释，但就像我说的那样；我不希望甲方加密消息，他们只应该知道如何解密它们。这就是为什么他们不知道他们的“公钥”。虽然它可能不被称为非对称加密，但这就是我想要找出的。

标签： encryption cryptography public-key-encryption encryption-asymmetric

【解决方案1】：

甲方能够使用公钥加密消息绝对没有问题。

只有您可以解密它们（使用您的私钥），并且由于您没有理由这样做，因此使用嵌入在您的应用程序中的公钥加密某些内容不会造成任何伤害 - 只是用户拥有的一堆无用数据，因为他不能解密它。

对于许可，您只需使用您的 private 密钥加密（或签名 - 就足够了，然后人们将能够读取许可文件中的限制等但不能修改它们）您的许可文件。然后应用程序使用嵌入的公钥解密文件（或验证签名）。

提取公钥并使用它签署自定义许可证文件的用户无法使用它，因为它只有在您的私钥嵌入应用程序时才能工作（因为这是解密使用公钥加密的内容所必需的密钥） .

但是，他可以很好地用自定义的公钥替换您的公钥（他也有私钥），然后使用他的私钥签署/加密他自己的许可证文件。不过，这不是密码问题——您只需要添加一些防破解/修改措施，以使替换嵌入式公钥变得更加困难。例如，您可以进行一些校验和验证。

【讨论】：

我会改写最后两段；在我阅读它的前几次，我很早就迷路了。但仍然是一个很好的答案。

【解决方案2】：

您的私钥在保险箱中，并发布您的公钥。创建许可证时，您使用您的私钥对其进行加密。客户端只能使用您的公钥对其进行解密。

如果您想将您的许可限制为客户，请让客户生成他们的密钥对，并将他们的公钥发送给您。然后，您使用他们的公钥加密许可证，然后使用您的私钥对其进行签名（或再次加密）。

当客户收到许可证时，他们必须 1.验证您发送给他们的许可证的签名（或解密） 2. 使用自己的私钥解密验证过的数据。

这确保了 1. 只有您可以向他们发送许可证，并且 2. 只有他们可以解密它。

【讨论】：

请注意，在这个意义上使用时，这些操作分别称为“签名”和“验证”，而不是“加密”和“解密”。区别很重要；例如，在 RSA 下，签名与加密时的填充要求完全不同。

【解决方案3】：

您通常会自己生成许可证，并使用您的私钥对其进行加密。然后您的客户可以使用您的公钥读取它。这是（非常广泛地说）证书方案（例如用于使用 HTTPS 进行安全在线浏览）的工作原理。是的，这仍然绝对算作非对称加密。

【讨论】：

【解决方案4】：

根据您的说法，非对称加密仍然是您想要的，只是需要以不同于您习惯的方式来完成。

假设您为 A 生成了一个密钥对。您向 A 发送了其中的一半：这并不重要，但我们将其称为私有一半。您使用公共部分进行加密并将其发送给 A。然后 A 可以对其进行解密。但是 A 将无法加密似乎来自 A 公钥的消息，因为它们只有密钥的私有一半，如果你只有一半，你就无法弄清楚密钥的另一半，不管你有哪一半。所以 A 只能加密可以被你保密的公钥解密的消息。

当然，正如其他发帖人已经说过的，有更好的方法来设置这个协议。一旦您了解了非对称加密的细节并回顾了我们喜欢称之为密钥半部分的内容以及我们通常如何使用它们，只是试图解释为什么这不是一个真正的问题。

【讨论】：

这在实践中很重要。在实践中，公钥可以从私钥生成。所以照你说的做，但是交换公共和私人，你会很好。

【解决方案5】：

您可以查看 Rhino 许可：http://hibernatingrhinos.com/open-source/rhino-licensing/introduction

【讨论】：

【解决方案6】：

其他答案已经说过如何做到这一点......这里只是一个注意事项（至少使用 RSA）您在问题中描述的方案是不安全的，如果它取决于 B 的密钥保密。

对于 RSA，公钥和私钥实际上是不对称的，您不能简单地交换它们并期望相同的安全属性。

如果您的乙方 (Bob) 使用相同的公钥加密多条消息，读取这些（密文）消息的攻击者可以轻松获得您的公钥。攻击者没有得到明文或私钥，但公钥总是会变得真正“公开”。
对于 A (Alice)，甚至可以从私钥创建公钥，而无需使用公钥加密任何消息。

我认为其他非对称密码系统也有类似的注意事项 - 始终仅按照指定和证明的方式使用它们。

在这种情况下，您可以组合两个密钥对：B 的一对用于签名/验证消息（以确保消息是由 B 发送的），而 A 的一对用于加密/解密消息（确保只有 A 可以阅读）。

【讨论】：

【解决方案7】：

是的。您可以使用 RSA 来实现 - 进行类似 Diffie-Hellman 的交换，因为不仅来自 1 个关联对的密钥可以交换，而且来自不同密钥对的密钥也可以交换。

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) )

请注意，我们在这里做了一些奇怪的事情。我们在一次操作中混合了来自不同密钥对的 RSA 操作。括号中的对象实际上是一个新的虚拟 RSA 密钥，这些密钥都不是公开的。如果我们尝试直接创建那个 RSA 密钥，那么 alice 或 bob 都会知道这对密钥的两个密钥。这个密钥对实际上是一个秘密密钥，你写到一端，只有另一端可以解密它，但你不能解密你自己写的东西，没有其他人可以加密到另一端的消息。

我从未见过有人像这样混合密钥对，但我通过编写代码对此进行了测试。我不得不做一些不寻常的事情，因为通常情况下，将私钥应用于消息是为了“签名”。但是签名通常会散列秘密并将私钥应用于它的散列；我们不想要的东西。所以在我的代码中，一旦我将 RSA 组件（D、E、N）提取为任意精度数......即：解密、加密、模数......我只是这样做了：

wormholeSend(me,you,msg) = (((me ^ {me_D}) \% me_N) ^ {you_E}) \% you_N

有点棘手的是，E（加密指数）实际上是一个可预测的值，但模数 N 在公钥 (E,N) 中。 D 对每一方都是私有的。这里我们需要小心，因为你和我的模数 N 不同。

我这样做是因为我想要一个系统，其中授权程序加密可由用户解密的密钥。这样做，用户不能加密密钥，程序也不能解密它们。

【讨论】：