在這種情況下，公鑰加密是唯一的選擇嗎？
兩方：客戶端和伺服器就對稱密鑰達成一致。客戶端和伺服器都知道
master password. 目前這樣做的方式是：
- 雙方都
master password使用 SHA-256 雜湊創建一個password hash.- 客戶端使用
password hash它來加密消息，其中包括 128 個偽隨機位等。然後將此加密消息發送到伺服器。- 伺服器檢查消息是否有效，因為它知道
master password和password hash. 如果消息確實有效，則伺服器還會生成一條消息（與客戶端消息的結構相似）並以相同的方式使用password hash. 然後，伺服器使用加密消息響應客戶端。- 客戶端使用
password hash.- 此時雙方已就 256 個隨機位（客戶端請求中的 128 位和伺服器響應中的 128 位）達成一致。
目的是確保：
- 恢復客戶端請求或伺服器響應的未加密內容是不可行的。
- 從客戶端請求或伺服器響應中恢復主密碼或密碼雜湊是不可行的。
問題是這種技術為離線攻擊留下了猜測主密碼的空間（可以處理線上攻擊），並且可能還有其他我還沒有想到的攻擊。這就引出了一個問題：
還有其他可能的攻擊嗎？
我認為我可以使用 PKC（特別是 RSA）在客戶端請求和伺服器響應上添加另一層加密（在 SKC 之上的 PKC），這樣攻擊者就無法在沒有 RSA 的情況下暴力破解低熵主密碼私鑰。
現在，出現了其他問題：
- 這是實現上述目標的有效方法嗎？
- 在這兩種情況下都有更好的解決方案嗎？
- 是否有不涉及 PKC 的解決方案？
- 哪些替代解決方案最安全？
“被加密”並不是終極目標。您不會為了數據而加密數據；您將數據加密作為確保給定安全屬性的一種方式，例如在兩台機器之間傳輸一些數據，而不會損害可能監視傳輸線（甚至更改傳輸中的數據）的攻擊者的數據機密性。
如果：
- 你的問題確實是數據傳輸的問題；
- 您可以安排發送者和接收者共享一個共同的密碼；
- 傳輸使用線上協議，消息可以雙向流動；
那麼您可以使用安全的數據隧道，通過密碼驗證密鑰交換協議來建立一個共享對稱密鑰（用於隧道加密和完整性），並具有與密碼相關的相互身份驗證。PAKE 協議確保攻擊者線上上進行間諜活動，甚至是可以嘗試冒充客戶端或伺服器的主動攻擊者，都不會學到任何可用於“猜測密碼”的資訊。使用 PAKE 協議，每個“密碼猜測”都必須暗示與誠實係統（真實伺服器或客戶端）的某種通信。然後，伺服器和客戶端只需數十次嘗試即可輕鬆檢測到暴力破解攻擊。因此，即使使用低熵密碼，PAKE 協議也是安全的。
帶有 PAKE 協議的安全隧道是一個複雜的野獸，在很多方面很容易出錯。因此，您確實應該依賴現有的、經過充分分析的協議。我建議使用 SRP 的 SSL/TLS；至少開源GnuTLS庫支持這一點。
如果傳輸是離線的（例如在電子郵件環境中：發件人必須一次性發送所有數據，而這對於之後才行動的接收者來說就足夠了），那麼密碼是不夠的，儘管你可以做到通過使用適當的密鑰派生過程對攻擊者來說相當困難，其中密碼使用隨機鹽多次散列。通常的建議是PBKDF2和bcrypt。如果您使用密鑰推導過程，則具有大約 30 位熵的密碼就足夠了，這意味著在相當新的 PC 上至少需要幾秒鐘的計算。
要獲得比這更高的安全性，您必須使用更強的共享密鑰；如果這意味著無法解決的密鑰分發過程，那麼您可以使用基於公鑰的方案，原型協議是OpenPGP（有關開源實現，請參閱GnuPG ）。您仍然需要確保發送者擁有真正的接收者的公鑰，但是（至少）這意味著不共享秘密數據。
**編輯：**隨著問題的新措辭，答案現在很清楚：PAKE。您希望通過基於密碼的相互身份驗證以及針對離線字典攻擊的彈性來獲得共享密鑰。PAKE 協議正是為此而設計的。所有目前已知的 PAKE 協議都涉及一些“類似公鑰”的元素，因此您至少不會避免一些數學問題。SRP 是一個適當的、有據可查的 PAKE 協議。