Draft-irtf-cfrg-hash-to-curve 中 map_to_curve 的複雜實現是怎麼回事？
我一直在研究實現cPace，我看到為其定義的兩個密碼套件引用了draft-irtf-cfrg-hash-to-curve的協議定義。cPace 的一部分需要將字元串雜湊映射到橢圓曲線上的一個點，因此它使用其他標準的方法來執行此操作，特別是它對
map_to_curve每條曲線的選擇。通過 draft-irtf-cfrg-hash-to-curve，它提供的選項
map_to_curve，例如 Simplified SWU 和 Elligator 2，對我來說似乎相當複雜。在我看來，例如，Elligator 2 正在執行很多步驟才能執行此映射。還有一些問題（一些實現）map_to_curve需要額外的步驟，例如將兩次呼叫相map_to_curve加以均勻分佈，並且必須從結果中刪除輔因子。在我看來，映射整數/欄位元素應該足夠簡單 $ u $ 只需使用即可到達曲線點 $ uG $ 和 $ G $ 作為曲線的生成器。我不明白為什麼不使用這種方法。通過對 Elligator 2 的研究，我發現它最初設計為雙向映射，但（草案）規範是在單向上下文中使用它。
什麼是（或可能是）為什麼使用 Elligator 2 等算法而不是僅僅使用 $ uG $ ? 到目前為止，我最好的猜測是效率，因為 Elligator 2 比計算更快 $ uG $ ，但我沒有找到任何考慮的證據，我不知道它是否更快。
作為後續問題，將Elligator 2 替換為 $ uG $ ? IE 會導致協議在加密上變弱嗎？我正在尋找實現 cPace，但我正在使用的庫 (OpenSSL) 沒有提供 Elligator 2 的實現，也沒有提供直接使用 X25519 上的曲線點來幫助我自己實現的介面，但它確實提供了訪問去表演 $ uG $ 作為其 DH 實施的一部分。
在我看來，映射整數/欄位元素應該足夠簡單 $ u $ 只需使用即可到達曲線點 $ uG $ 和 $ G $ 作為曲線的生成器。
這確實很簡單；但是，使用它會喪失 cPace 的安全屬性。
這就是為什麼；cPace 的工作原理是讓雙方將秘密密碼（和一些隨機數）映射到橢圓曲線點，然後讓雙方對橢圓曲線點執行 DH 操作。一般的想法是，如果您是一個猜測密碼的主動攻擊者（並且該猜測是錯誤的），您將不知道有效系統（知道密碼）將使用的秘密，因此您贏了無法預測共享的秘密（甚至無法辨識它）。
但是，這是攻擊者可以使用您的密碼散列方案執行的操作；攻擊者可以選擇一個密碼，並在假設密碼正確的情況下實施協議；也就是說，他產生了一個點 $ H = hash(password)G $ , 生成一個隨機值 $ x $ , 計算 $ xH $ ，將其發送到受到攻擊的系統；該系統發送一個點 $ J $ （這是他的 $ yH $ 值）然後你計算 $ xJ $ ; 然後，受到攻擊的系統會根據他計算出的秘密發送一條加密的消息。
如果攻擊者對密碼的猜測是正確的，那麼雙方將生成相同的秘密，因此攻擊者可以解密消息——這並不奇怪。但是，假設最初的密碼猜測是錯誤的。然後，攻擊者可以做的是再次猜測密碼，併計算 $ H’ = hash(password’)G $ 併計算 $ x’ = hash(password) hash(password’)^{-1} x $ . 請注意，這些值 $ x’H’ = xH $ ，因此使用此密碼（並已修改 $ x’ $ ) 我們會發送完全相同的 DH 公共值；所以，我們可以計算 $ x’J $ （基於對方發送的點），並使用它來計算共享秘密，然後解密加密的消息 - 如果他第二次猜測密碼是正確的，那麼這將起作用。
他可以執行相同的程序以允許他檢查他的密碼字典中的每個密碼；這違反了 cPace 應該具有的安全屬性，即在單次交換之後，攻擊者可以了解對密碼的猜測是否有效，而絕無其他。
map_to_curve 過程旨在避免這種情況 - 給定由兩個不同密碼生成的兩個點，您無法確定兩者之間的關係（因此上述攻擊不起作用）。