如果公共密鑰存儲在服務器上怎麼辦？

通過java腳本算法在客戶端創建公鑰和私鑰對，然後將公鑰傳輸到服務器。如果公共密鑰存儲在服務器上怎麼辦？

人員私鑰的副本以java腳本變量的形式存儲在用戶計算機上。

當用戶A將消息發送到用戶B

服務器加密與用戶B的公開密鑰對消息。

用戶B拿起消息並解密（用java腳本編寫的算法）它與用戶B的私有密鑰私有並保存在一個Java腳本變量中。

用戶B的私鑰在任何時候都不會在網絡上被披露。

這是安全嗎？

來源

2012-07-19 Ere

如果以下任何答案對您有用，請將其標記爲已接受，以便人們不會再花時間處理此問題。 – techfoobar 2012-07-20 19:07:57

在任何人都可以回答「這是安全的」問題之前，您需要解釋您的威脅模型是什麼。也就是說，誰是你的攻擊者，他們的目標是什麼，他們有什麼資源？ – 2012-07-23 05:08:02

'public'和'private'只是給兩個鍵的名字。沒關係這兩個鍵中的哪個是公開的，哪些是私有的，只要你永遠不要混淆使用。一旦兩個密鑰同時對某個人可用，消息系統的安全性就會完全被破壞。

從技術上講，既然你說的關鍵字存儲在JavaScript變量，你暗示變量被髮送到嵌入在某些基於瀏覽器的HTML/JavaScript的CLEAR中。這進一步意味着沒有安全性 - 因爲這兩個密鑰都暴露在網絡中。

來源

2012-07-19 17:38:13

回覆：「既然你說的鍵存儲在JavaScript變量，你暗示變量被髮送到嵌入在一些基於瀏覽器的HTML/JavaScript中的CLEAR」：這是不正確的。 OP明確指出：「公鑰和私鑰對是通過Java腳本算法在客戶端創建的，然後將公鑰傳輸到服務器。」 – ruakh 2012-07-19 17:39:26

「'public'和'private'只是兩個鍵的名字，兩個鍵的哪一個是公共的，哪一個是私人的並不重要。」 - 這是一個泛化，並不總是如此。一些PK算法以這種方式是對稱的，但另一些則不是。 – 2012-07-23 05:07:12

它不會太安全，因爲：

任何用戶（比如用戶B）的私鑰可以通過注入JS代碼，或壞的瀏覽器插件向外泄露您的應用程序的
一旦完成，任何人可以訪問任何針對用戶B的消息，將能夠解密並理解它
當然，如果您是唯一使用應用程序的用戶，因爲你可能有其他用戶使用不同的瀏覽器設置/插件/瀏覽行爲等，這是完全可能的
當用戶A試圖發送一些東西給用戶B時，你說服務器會使用用戶B的公鑰加密消息 - 現在，這個通過JS創建的請求可以由中間人解釋。一旦完成，這個中間人可以通過操縱發件人，引用者等向任何用戶發起任何請求。這可以導致冒充等等。
你還提到，在生成之後，你打算將公鑰發送給服務器。 JS的這個調用很容易被解釋，這意味着公鑰可能被泄露。

來源

2012-07-19 17:41:51 techfoobar

要確定某件事是否「安全」，您必須知道安全要求是什麼。您的情況滿足幾個可能的要求，但有幾個可能的要求，它確實而不是滿足。例如：

該消息的明文副本顯然是通過網絡從用戶A傳輸到服務器，因此任何人都可以在該點上對其進行竊聽。（這可能是一個嚴重的問題。）
你不解釋如何將公鑰傳送給服務器。如果它不是以認證方式傳輸的，那麼中間人可以生成他自己的公私密鑰對，並將他的公鑰發送給服務器。（這可能是一個嚴重的問題。）
用戶B無法驗證他收到的消息的真實性。該消息可能來自服務器（最終來自用戶A），或者可能來自其他任何擁有公鑰副本的人。（這可能會或可能不會是一個嚴重的問題，這取決於應用程序。）

所以，總體來說，我會不考慮這樣的設計是「安全的」。

來源

2012-07-19 17:44:34 ruakh

如果公共密鑰存儲在服務器上怎麼辦？

回答

相關問題