整個過程就是設計一個簡單的系統，用戶可以在它們之間發送加密的消息（在服務器的支持下）。帶用戶選擇密碼的公鑰密碼術？
在這種情況下，客戶端沒有本地存儲，所以我不得不使用密碼，用戶可以根據需要選擇，記住和鍵入密碼。 （我知道這削弱了整個系統，但是這是一個硬性要求）
另一個要求是服務器不能存儲明文私鑰或可用於（例如解密消息任何其他數據：僅用戶可以讀取加密的消息，服務器管理員不應該能夠）。
我的方法是在客戶端上生成非對稱密鑰對，並在服務器上發佈公鑰和私鑰的加密副本（使用用戶密碼加密）。 用戶可以使用收件人發佈的公鑰將加密郵件發送給其他用戶;當用戶需要解密消息時，他的（加密的）私鑰在客戶端從服務器獲取，用用戶提供的密碼解密，然後用於解密消息。
這是否有意義？這個系統設計有什麼缺陷嗎？ （除了由用戶選擇短密碼或壞密碼導致的弱點） 這種方法是否已經用於類似的場景？
謝謝:)
如果我理解正確，您希望創建一個系統，讓兩個用戶可以通過他們不信任的服務器發起私人通信。
這不起作用。
在您設計的場景中，服務器可以生成自己的密鑰對，並將公鑰發佈爲用戶的公鑰。當用戶加密消息並將其用於他們的合作伙伴時，他們無法檢測到該服務器已替換其公鑰。服務器解密該消息，將其呈現給服務器管理員，並用真實夥伴公鑰將其重新加密（或他們捏造的一些新消息），並將其轉發到目的地。
這裏缺少的是證書頒發機構。這是一個可信的第三方，它對公鑰和用戶名之間的綁定進行了數字簽名。這種綁定稱爲證書。這樣，當服務器向客戶端提供公用密鑰以用於加密時，客戶端可以使用CA的公鑰來驗證證書，並且確信他們將要加密的公鑰屬於預期的收件人，而不是攻擊者。
用戶必須信任CA，這可能比信任服務器管理員更可口。但是，還必須有防篡改的方式來存儲CA證書。實際上，這通常是使用基於密碼的MAC（消息認證碼）完成的。或者，CA可以用用戶的私鑰進行數字簽名（從未見過這樣做，但它會起作用）。但棘手的部分是從可信來源獲得CA證書，繞過不可信賴的服務器。
至於用密碼加密私鑰，這是經常完成的，並且與您選擇的密碼一樣安全。
或者，如果用戶可以在帶外彼此共享一個祕密，則不需要公共密鑰加密。客戶端可以使用用戶選擇的密碼加密共享密鑰，並將密文存儲在服務器上。
是的，它看起來不起作用。猜猜我必須找到一種方法來使用受信任的CA :)謝謝你的建議。 無論如何，只要知道，假設服務器沒有被篡改，只能獲得*讀取*訪問服務器的攻擊者將無法截取任何東西，對嗎？另外，如果將信任與一個不同的系統一次性分配（例如，使用可以與受信任的CA進行驗證的客戶端），然後在服務器上進行存儲（加密），那麼它應該可以工作，不是嗎？ – Patonza 2010-12-18 00:42:25
@Patonza - 是的，如果信任最初是由可信任的CA建立的，那麼客戶端可以將合作伙伴的公鑰存儲在服務器上*使用他們自己的密碼對其進行身份驗證（而不是*加密*）。由於存儲的數據受到MAC保護，服務器不能篡改它。 – erickson 2010-12-18 02:05:49
如果攻擊只能在服務器上讀取訪問權限，則無法更改通過它的消息，如果這就是您的意思。但是我描述的攻擊是服務器本身腐敗的地方。 – erickson 2010-12-18 02:08:33
如上所述，該方案似乎是合理的，因爲它應該允許有人給另一個人的消息，只有收件人才能閱讀。有一些項目浮現在腦海中，你可能已經想到了，但是忽略了爲簡潔：
非常感謝您關於發送者身份/消息身份驗證的觀點，儘管不是我在此特定設計中的優先考慮事項：有趣的是，消息可以使用另一個密鑰對進行簽名，並且客戶端可以在服務器上存儲已知/可信發件人密鑰的加密目錄 - 我會研究這個。我會遵循您對PBKDF2的建議，這似乎是關鍵強化的行業標準。 :) – Patonza 2010-12-17 23:57:06
@Patonza - 沒有身份驗證，你不能擁有隱私。隱私意味着保守「某人」的祕密。如果你不知道你在跟誰說話，你怎麼知道這不是「某人」？ – erickson 2010-12-18 00:22:47
P.S.雖然我認爲這個答案是錯誤的（這意味着所提議的系統將只允許預期的收件人解密一條消息），但是每個要點中的建議都非常好，如果實施真正的系統，應該仔細考慮。 – erickson 2010-12-18 00:25:21
這聽起來像什麼hushmail做。然而，有一個主要的問題在於，由於他們擁有用戶的私鑰（加密的），他們只需按下被黑客入侵的Java小程序就可以將用戶的密碼傳輸到服務器（他們所做的）。
一個更好的解決方案是避免在服務器上擁有該私鑰。由於沒有本地存儲的要求，那就沒有了。
爲什麼不通過預共享密碼使用對稱加密？它可以在客戶端沒有存儲的情況下完成。我相信這就是@erickson在他最後一段中所說的。
我不假設客戶端代碼必須從服務器上下載。它可以在客戶端以只讀方式存儲。對稱加密在這裏不是一種選擇，因爲用戶在共享數據之前必須先「相遇」。無論如何感謝您的建議:) – Patonza 2010-12-18 09:55:39
主要問題是，如果解密代碼是從服務器下載的，則一個（服務器管理員或到服務器的黑客）都可以替換此代碼。客戶端的用戶應該信任服務器，但他無法驗證服務器以信任它。
如上所述，它聽起來類似於hushmail.com的做法。他們在其網站上有描述安全性的白皮書。 – 2010-12-18 01:08:42
謝謝，我會看看他們。 – Patonza 2010-12-18 09:56:38