Elliptic-Curves
基於 Diffie-Hellman 的密碼挑戰響應方案
一個非常常用的（例如：HTTP digest auth / CHAP / Kerberos）身份驗證方案如下所示：
設置。
- 客戶端和伺服器都知道密碼 $ p $ .
驗證。
- 伺服器發送隨機挑戰 $ \alpha $ .
- 客戶端計算 $ r = \text{KDF}(p || \alpha) $ 並發送 $ r $ 到伺服器。
- 伺服器計算 $ r’ = \text{KDF}(p || \alpha) $ 並檢查 $ r’ \overset{?}{=} r $ .
該方案也在其他問題（範例）中進行了描述。現在這種方案有個缺點，就是伺服器需要知道明文密碼。我們可以為質詢響應認證制定一個基於公鑰的方案嗎？
例如，我們可以使用橢圓曲線算法：
設置。
- 客戶有一個秘密密碼 $ p $ （具有合理的熵）並由此得出一個密鑰 $ k $ 使用雜湊函式。
- 客戶端計算 $ [k]P = Q_k $ 並且伺服器會將這個值儲存為使用者的公鑰。
驗證。
- 伺服器發送隨機挑戰 $ Q_\alpha = [\alpha]P $ .
- 客戶端計算 $ Q_s = [k]Q_\alpha $ 並發送 $ Q_s $ 到伺服器。
- 伺服器計算 $ Q_s’ = [\alpha]Q_k $ 並檢查 $ Q_s’ \overset{?}{=} Q_s $ .
這個方案有效嗎？為什麼大多數係統會改用基於 HMAC 的方案？
首先，您在這裡嘗試建構的內容稱為增強或非對稱 基於密碼的密鑰交換(aPAKE)。至於你的混凝土結構：
這個方案有效嗎？
是的，它在功能上是正確的。
它真的實現了 aPAKE 方案的安全保證嗎？不，攻擊者可以查看記錄，請參閱 $ Q_s=[k]Q_a $ 並且都知道 $ Q_s $ 和 $ Q_a $ 因此可以離線暴力破解密碼。
您提到的第一個（對稱）方案也存在同樣的問題。
我們可以為質詢響應認證制定一個基於公鑰的方案嗎？
這就是 aPAKE 方案所做的，最值得注意的協議是：
- 安全遠端密碼協議(SRP)，主要是因為它首先在RFC 2945中被標準化。
- OPAQUE是目前最先進的（簡單）aPAKE。
- 如果您還想為使用者假設第二個輔助設備，OpTFA是最先進的。
- 如果使用者“僅”擁有能夠執行 (EC)DH 密鑰協議的設備（如智能卡），那麼PTR-PAKE是您可以獲得的最佳選擇。
OPAQUE 和 PTR-PAKE 的範例實現（在 C 中）可以在libsphinx中找到。