2

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

  • 甲方拥有公私钥
  • 乙方用甲的公钥加密东西
  • 甲方用他们的私钥解密东西

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

  • 甲方有私钥
  • 乙方有一个私钥（即甲方的公钥）
  • 乙方用他们的私钥加密东西
  • 甲方用他们的私钥解密东西

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

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

4

7 回答 7

3

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

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

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

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

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

于 2011-04-14T11:58:14.230 回答
2

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

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

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

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

于 2011-04-14T11:58:14.370 回答
1

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

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

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

于 2011-04-14T12:02:49.783 回答
1

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

于 2011-04-14T11:57:51.783 回答
1

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

于 2011-04-14T12:03:33.920 回答
1

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

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

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

我想其他非对称密码系统也有类似的警告 - 总是只使用它们，就像它们被指定和证明一样。

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

于 2011-08-12T22:37:44.400 回答
0

是的。您可以使用 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 不同。

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

于 2015-12-13T15:23:41.807 回答