帶加密公鑰和私鑰對的大難題概念

我正在創建一個RESTful API Web服務，我需要一種實現公鑰和私鑰對的方式。帶加密公鑰和私鑰對的大難題概念

我將使用PHP的一些內置函數來創建我自己的算法來生成這兩個鍵的值。

我只需要了解一般系統背後的概念或邏輯。

示例客戶端和服務器具有公鑰和私鑰值。然後用服務器端解碼的客戶端上的另一個算法合併密鑰，如果匹配，則顯示請求的資源？

還是我對他們的方式標記？任何鏈接或建議將得到很好的評價

來源

2011-10-12 user866190

私鑰生成並存儲在服務器上的密鑰庫中。使用私鑰生成公鑰。該公鑰提供給其他人（例如瀏覽器）來加密消息以將* back *發送給服務器，服務器只能（有希望地）使用密鑰庫中的私鑰解密。 –

但是，一個*私人*鍵的重點是**而不是**。 '：）' –

有幾個算法使用私有/公鑰對。它們的三種常見用途是：加密/解密，簽名/驗證和密鑰協議。

對於加密/解密，數據僅使用公鑰進行加密，並使用私鑰進行解密。 RSA算法就是一個例子。

對於簽名/驗證，數據使用私鑰進行簽名，並使用公鑰進行驗證。 DSA算法就是一個例子。

對於密鑰協議，有兩方使用其公鑰/私鑰。各方交換其公鑰，並使用私鑰，公鑰和對端公鑰生成共享密鑰。 Diffie-Hellman（DH）算法就是一個例子。

正如名字所暗示的，對於任何一方，你都不會給你的私鑰。您可以放心地在任何地方發佈您的公鑰。只有公鑰，你不能執行上面需要私鑰的任何任務 - 並且顯然在給定公鑰的情況下計算私鑰是不可行的。

來源

2011-10-12 23:21:08 vhallac

公鑰/私鑰加密的一個更具挑戰性的方面是理解公鑰是給予發件人的，發件人然後編碼（加密）發件人將生成的郵件發回給收件人（誰擁有公鑰/私鑰）。所以從某種意義上說，這是一種相反的情況，消息發送者接收公鑰，消息接收者發送公鑰來接收未來的消息，並且總體上**兩個**通常都是交易頭寸（例如瀏覽器/服務器，例如）。 –

而第二個也被稱爲不可否認，對嗎？ –

@JaredFarrish真的。簽名操作做了兩件事：確認你發送的消息確實來自你，並且允許接收者稍後證明它來自你（不可否認術語來自後者）。 – vhallac

帶加密公鑰和私鑰對的大難題概念

回答

相關問題