根据维基百科(和其他来源)，非对称加密总是这样工作的:
- 甲方拥有公钥和私钥
- 乙方使用A的公钥加密内容
- 甲方用私钥解密资料
然而，我不希望甲方能够加密他们自己的数据，只希望他们能够解密。使用非对称逻辑，这将导致:
- 甲方有私钥
- 乙方拥有私钥(即甲方的公钥)
- 乙方用私钥加密物品
- 甲方用私钥解密资料
我们将使用它进行某种许可证生成/检查。我们的客户端可能不生成许可证，但许可证文件必须在客户端可读。
这仍然是非对称加密还是我应该寻找不同的方法?
甲方能够使用公钥加密消息绝对没有问题
只有你可以解密它们(用你的私钥)，因为你没有理由这样做，用嵌入在你的应用程序中的公钥加密东西不会造成任何伤害——只是一堆无用的数据，因为用户无法解密。
对于许可，您只需加密(或签名-这就足够了，然后人们将能够读取许可证文件中的限制等，但不能修改它们)使用您的私有密钥您的许可证文件。然后应用程序使用嵌入的公钥解密文件(或验证签名)。
用户提取公钥并使用它签署自定义许可文件不能使用它，因为它只有在您的私钥嵌入到应用程序中时才有效(因为这是解密用公钥加密的内容所必需的密钥)。
但是，他可以很好地将您的公钥替换为自定义公钥(其中他也有私钥)，然后使用他的私钥签名/加密他自己的许可证文件。不过，这不是一个加密问题——您只需要添加一些防破解/修改措施，以使替换嵌入的公钥变得更加困难。例如，您可以执行一些校验和验证。
您将私钥放在保险箱中，并发布您的公钥。当您创建许可证时，使用您的私钥对其进行加密。客户端只能用你的公钥解密。
如果你想限制你的许可证给一个客户端，要求客户端生成他们的密钥对，并发送他们的公钥给你。然后你用他们的公钥加密许可证，然后用你的私钥签名(或再次加密)。
当客户端收到许可证时，他们将不得不1. 验证您发送给他们的许可证的签名(或解密)2. 使用他们自己的私钥解密验证的数据。
这确保了1。只有你可以把许可证和2发给他们。只有他们能解密。
您通常要做的是在您这边生成许可证，并用您的私钥加密它。然后，您的客户端可以使用您的公钥读取它。这(非常广泛地说)就是证书方案(例如使用HTTPS的安全在线浏览)的工作方式。是的，这仍然可以算作非对称加密。
根据你所说的，非对称加密仍然是你想要的，它只是需要以一种不同于你习惯思考的方式来完成。
假设你为a生成了一个密钥对，你将密钥对的一半发送给a:这并不重要，但我们将其称为私有的一半。您使用公开的一半加密并将其发送给A，然后A可以解密它。但是A不能加密一条看起来来自A公钥的消息，因为他们只有私钥的一半，如果你只有一半，你就无法知道另一半的密钥，不管你有哪一半。因此，A只能加密可以被您作为秘密保存的公钥解密的消息。
当然，正如其他海报已经说过的，有更好的方法来设置这个协议。我只是想解释一下为什么这不是一个问题一旦你了解了非对称加密的细节，并了解了我们喜欢称之为密钥一半的东西以及我们通常是如何使用它们的。
您可以查看Rhino许可:http://hibernatingrhinos.com/open-source/rhino-licensing/introduction
其他的答案已经说了怎么做…这里需要注意的是(至少对于RSA)你在问题中描述的方案是不是安全的，如果它依赖于B的密钥保密的话。
对于RSA， 公钥和私钥实际上是不对称的，你不能简单地交换它们并期望相同的安全属性。
- 如果您的乙方(Bob)使用相同的公钥加密多条消息，则读取这些(密文)消息的攻击者可以毫不费力地获得您的公钥。攻击者无法获得明文或私钥，但公钥将始终成为真正的"公开"。
- 对于A (Alice)来说，甚至可以从私钥中创建公钥，而不需要用公钥加密任何消息。
我想对于其他非对称密码系统也有类似的警告——总是只在它们被指定和证明时使用它们。
在这种情况下，您将组合两个密钥对:B的一个用于签名/验证消息(以确保消息是由B发送的)，A的一个用于加密/解密消息(以确保只有A可以读取它)。是。你可以用RSA来做一个类似迪菲-赫尔曼的交换，因为不仅来自一个关联对的密钥可以交换，而且来自不同对的密钥也可以交换。
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
我这样做是因为我想要一个系统，其中程序被授权加密可以由用户解密的密钥。这样做，用户不能加密密钥，程序也不能解密它们。