根据维基百科（和其他来源），非对称加密始终是这样的：我可以使用两个私钥进行非对称加密吗？
不过，我不希望甲方能够加密自己的数据，只希望他们能够解密吧。使用非对称逻辑，这将导致：
我们将使用这对于一些形式的授权代/检查。我们的客户可能不会生成许可证，但许可证文件必须在客户端可读。
这仍然是不对称加密或者我应该看不同的方法？
你必须在安全的私有密钥，并发布你的公钥。当您创建许可证时，使用您的私钥对其进行加密。客户端只能用公钥解密。
如果你想限制你的许可证到客户端，请客户端生成他们的密钥对，并将他们的公钥发送给你。然后，您使用其公钥对许可证进行加密，然后使用您的私钥对其进行签名（或再次对其进行加密）。
当客户端收到许可证时，他们将不得不 1.验证您发送给他们的许可证的签名（或解密） 2.使用他们自己的私钥解密验证的数据。
这确保了1.只有你可以给他们发送许可证和2.只有他们可以解密它。
请注意，在这种意义上使用时，操作分别称为“签名”和“验证”，而不是“加密”和“解密”。区分*很重要;例如，在RSA下，签名时的填充要求完全不同于加密。 – caf 2011-04-15 04:07:15
什么，你通常会做的是生成你在你的身边许可，并用私钥加密。然后你的客户可以使用你的公钥读取它。这是（非常广泛地）证书方案（如用于安全在线浏览HTTPS）的工作方式。是的，这仍然是非对称加密。
甲方能够使用公共密钥来加密消息是绝对没问题。
只有你可以使用你的私钥对它们进行解密，既然你没有理由这样做，那么使用应用程序中嵌入的公钥来加密某些内容将不会造成任何伤害 - 只是用户拥有的一堆无用数据不能解密它。
对于您只需加密许可（或签字 - 这就够了，然后人们将能够读取许可证文件的限制等，但不modidy他们）使用私人密钥您的许可文件。然后应用程序使用嵌入的公钥解密文件（或验证签名）。
用户提取公钥并用它对自定义许可证文件进行签名将无法使用它，因为只有当您的私钥被嵌入到应用程序中时它才会起作用（因为这是解密使用公钥加密的内容的密钥）。
不过，他很可能取代一个自定义您的公钥（在那里他有私钥，太），然后登录/使用自己的私钥加密自己的许可文件。这并不是虽然密码学的问题 - 你只需要添加一些抗龟裂/修改措施，使其难以替代嵌入式公钥。例如，你可以做一些校验和验证。
我会重写最后两段;我很早就在那里读了很多次。但是，一个很好的答案。 – Slartibartfast 2011-05-13 02:08:09
根据你所说的话，非对称加密仍然是你想要的，它只是需要以不同于你习惯思考的方式来完成。
假设您为A生成了一个密钥对。您发送一对一半的密钥对：它并不重要，但我们将其称为私有密钥对的一半。你使用公开的一半进行加密并将它发送给A.然后A可以解密它。但是A将不能加密看起来来自A公钥的消息，因为它们只有私钥的一半，如果只有一半的密钥，你就无法弄清另一半的密钥，不管你有哪一半。所以A只能加密可以被您保密为秘密的公钥解密的邮件。
当然，正如其他海报已经说过的，有更好的方法来建立这个协议。试图解释一下，为什么这不是真正的问题，一旦你了解了非对称加密的细节，并看看我们喜欢称之为关键的一半以及我们通常如何使用它们。
它在实践中很重要。实际上，公钥可以从私钥生成。所以尽你所说，但交换公共和私人，你会很好。 – Slartibartfast 2011-05-13 02:05:00
其他的答案已经说怎么办呢？这里只是一张纸条，上面（与RSA至少），你在你的问题中描述的方案是不是安全，如果它取决于B的关键保持秘密。
对于RSA，公钥和私钥真的是不对称的，并且您不能简单地交换它们并期望相同的安全属性。
我想对于其他非对称密码系统也有类似的注意事项 - 总是只使用它们，就像它们被指定并证明一样。
在这种情况下，您可以合并两个密钥对：B是签名/验证消息（以确保消息由B发送），A是加密/解密消息（以确保只有A可以阅读它）。
是的。你可以用RSA来做 - 做一个类似Diffie-Hellman的交换，因为不仅一对关联对中的关键字可以通勤，而且来自不同关键对的关键字也可以通勤。我们做了一个奇怪的现象在这里
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密钥，爱丽丝或鲍勃都会知道这对密钥。这个密钥对实际上是一个秘密密钥，你写信给一端，只有另一端可以解密它，但是你不能解密你自己写的东西，也没有人能够将消息加密到另一端。
我从来没有见过任何人混合这样的keypairs，但我通过编写代码来测试这个。我不得不做一些不寻常的事情，因为通常情况下，将私钥应用于消息是为了'签署'。但是签名通常会散列秘密，并将私钥应用到它的散列;我们不想要的东西。所以，在我的代码，一旦我有RSA组件（d，E，N）提取到任意精度的数字...即：解密，加密模...我只是做：
wormholeSend(me,you,msg) = (((me^{me_D}) \% me_N)^{you_E}) \% you_N
的有点棘手的是E（加密指数）实际上是一个可预测的值，但模数N在公钥（E，N）中。 D对每一方都是私密的。我们在这里需要小心，因为你和我有不同的模数N.
我这样做是因为我想要一个系统，一个程序被授权对用户可以解密的密钥进行加密。这样做，用户无法加密密钥，并且程序无法解密它们。
B的* private *键也可以成为A的* public *键吗？根据定义，两者是相互排斥的。私密应该保密，不公开。 – Mac 2011-04-14 11:54:21
这很难解释，但正如我所说;我不想让A方加密消息，他们只知道如何解密它们。这就是为什么他们不知道他们的“公共”钥匙。它可能不会被称为不对称加密，但这正是我试图找到的。 – SaphuA 2011-04-14 11:56:27