根據維基百科（和其他來源），非對稱加密始終是這樣的：我可以使用兩個私鑰進行非對稱加密嗎？
不過，我不希望甲方能夠加密自己的數據，只希望他們能夠解密吧。使用非對稱邏輯，這將導致：
我們將使用這對於一些形式的授權代/檢查。我們的客戶可能不會生成許可證，但許可證文件必須在客戶端可讀。
這仍然是不對稱加密或者我應該看不同的方法？
你必須在安全的私有密鑰，併發布你的公鑰。當您創建許可證時，使用您的私鑰對其進行加密。客戶端只能用公鑰解密。
如果你想限制你的許可證到客戶端，請客戶端生成他們的密鑰對，並將他們的公鑰發送給你。然後，您使用其公鑰對許可證進行加密，然後使用您的私鑰對其進行簽名（或再次對其進行加密）。
當客戶端收到許可證時，他們將不得不 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