帶用戶選擇密碼的公鑰密碼術？

Question

整個過程就是設計一個簡單的系統，用戶可以在它們之間發送加密的消息（在服務器的支持下）。

在這種情況下，客戶端沒有本地存儲，所以我不得不使用密碼，用戶可以根據需要選擇，記住和鍵入密碼。 （我知道這削弱了整個系統，但是這是一個硬性要求）

另一個要求是服務器不能存儲明文私鑰或可用於（例如解密消息任何其他數據：僅用戶可以讀取加密的消息，服務器管理員不應該能夠）。

我的方法是在客戶端上生成非對稱密鑰對，並在服務器上發佈公鑰和私鑰的加密副本（使用用戶密碼加密）。 用戶可以使用收件人發佈的公鑰將加密郵件發送給其他用戶;當用戶需要解密消息時，他的（加密的）私鑰在客戶端從服務器獲取，用用戶提供的密碼解密，然後用於解密消息。

這是否有意義？這個系統設計有什麼缺陷嗎？ （除了由用戶選擇短密碼或壞密碼導致的弱點） 這種方法是否已經用於類似的場景？

謝謝:)

Answer 1

如果我理解正確，您希望創建一個系統，讓兩個用戶可以通過他們不信任的服務器發起私人通信。

這不起作用。

在您設計的場景中，服務器可以生成自己的密鑰對，並將公鑰發佈爲用戶的公鑰。當用戶加密消息並將其用於他們的合作伙伴時，他們無法檢測到該服務器已替換其公鑰。服務器解密該消息，將其呈現給服務器管理員，並用真實夥伴公鑰將其重新加密（或他們捏造的一些新消息），並將其轉發到目的地。

這裏缺少的是證書頒發機構。這是一個可信的第三方，它對公鑰和用戶名之間的綁定進行了數字簽名。這種綁定稱爲證書。這樣，當服務器向客戶端提供公用密鑰以用於加密時，客戶端可以使用CA的公鑰來驗證證書，並且確信他們將要加密的公鑰屬於預期的收件人，而不是攻擊者。

用戶必須信任CA，這可能比信任服務器管理員更可口。但是，還必須有防篡改的方式來存儲CA證書。實際上，這通常是使用基於密碼的MAC（消息認證碼）完成的。或者，CA可以用用戶的私鑰進行數字簽名（從未見過這樣做，但它會起作用）。但棘手的部分是從可信來源獲得CA證書，繞過不可信賴的服務器。

至於用密碼加密私鑰，這是經常完成的，並且與您選擇的密碼一樣安全。

或者，如果用戶可以在帶外彼此共享一個祕密，則不需要公共密鑰加密。客戶端可以使用用戶選擇的密碼加密共享密鑰，並將密文存儲在服務器上。

Answer 2

如上所述，該方案似乎是合理的，因爲它應該允許有人給另一個人的消息，只有收件人才能閱讀。有一些項目浮現在腦海中，你可能已經想到了，但是忽略了爲簡潔：

• 當加密私鑰，使用類似PBKDF2鹽和一些它迭代iterations相當大的數字。
• 這可能是暗示的，但不是使用公鑰進行加密，而是生成隨機密鑰（例如，如果使用例如AES-256，則爲32字節的隨機數據）可能是有意義的。使用該密鑰加密消息，使用公鑰對密鑰進行加密，然後發送這兩個消息。
• 如上所述，沒有識別發件人。它允許純粹匿名的消息被髮送。這可能是有意的，但如果不是的話，那麼某種識別/認證將是必要的。
• 與前面的條目有些相似，沒有描述消息認證。攻擊者可能會更改加密的消息，並且收件人將無法辨別其已更改。雖然，如果它是一條短信，它會很明顯的被修改，因爲它只是亂碼文本。然而，有些類型的數據可能不太容易判斷它是否已被修改。

Answer 3

這聽起來像什麼hushmail做。然而，有一個主要的問題在於，由於他們擁有用戶的私鑰（加密的），他們只需按下被黑客入侵的Java小程序就可以將用戶的密碼傳輸到服務器（他們所做的）。

一個更好的解決方案是避免在服務器上擁有該私鑰。由於沒有本地存儲的要求，那就沒有了。

爲什麼不通過預共享密碼使用對稱加密？它可以在客戶端沒有存儲的情況下完成。我相信這就是@erickson在他最後一段中所說的。

Answer 4

主要問題是，如果解密代碼是從服務器下載的，則一個（服務器管理員或到服務器的黑客）都可以替換此代碼。客戶端的用戶應該信任服務器，但他無法驗證服務器以信任它。