是否有一種方案可以在不洩露種子的情況下強制執行隨機種子？
端到端加密 Web 服務（如 cryptpad）通常在 URL 的雜湊部分（不發送到伺服器）中包含一個 128 位種子，以派生髮送到伺服器的標識符和僅在客戶端使用的加密密鑰。與直接儲存標識符和加密密鑰相比，此種子允許使用更短的 URL。
然而，雖然非加密標識符通常由伺服器生成，但種子需要專門在客戶端生成，因此加密密鑰仍然保密。因此，修改後的客戶端可以選擇任意種子，例如在 URL 中編碼時的可讀名稱。是否有防止任意種子的加密方案？像這樣的東西：
- 伺服器向客戶端發送熵 E。
- 客戶端根據 E 和額外熵 E’ 生成種子 S。伺服器無法推斷 S。S 應該很短（~ 128 位）。S僅基於E，以確保客戶端不能自由選擇S。
- 客戶端確定性地從 S 導出標識符 I（128 位）和加密密鑰 K（128 位）。
- 客戶端向伺服器顯示 I 並證明 I 是間接基於 E 而不顯示 E’、S 或 K。然後，伺服器可以允許創建具有標識符 I 的資源。
為了證明，伺服器和客戶端之間的多次往返是可以接受的。
使用 Ed25519：
團體規模 $ \ell $ 由基點生成 $ G $ 曲線上大約是 $ 2^{252} $ . 作為縮寫，以下對“252 位”數字的引用指的是小於 $ \ell $ .
客戶端具有 127 位熵 $ e $ ，並選擇一個均勻隨機的 252 位標量 $ b $ .
客戶端使用 $ b $ 作為得出 Pedersen 承諾的致盲因素 $ C=eG+bH $ . $ H $ 是曲線上第二個眾所周知的基點，使用“nothing-up-my-sleeve”技術選取，使得離散對數 $ H $ 寫 $ G $ 是不可知的。
客戶端發送 $ C $ 到伺服器，伺服器選擇隨機的 127 位熵 $ e’ $ . 伺服器發送 $ e’ $ 給客戶。
客戶端計算 128 位種子 $ s=e+e’ $ .
客戶計算第二個承諾 $ C’=C+e’G $ ，並且伺服器也計算相同的值 $ C’ $ 為自己。
這將意味著 $ C’=C+e’G==eG+bH+e’G==(e+e’)G+bH==sG+bH $ .
此時，伺服器可以允許 $ H_{128}(C’) $ 作為標識符，其中 $ H_{128}(\texttt{input}) $ 表示對輸入進行散列（使用加密安全散列，例如 SHA512）並返回結果的前 128 位。
但是，這將要求客戶不僅要記住 $ s $ , 也是致盲因素 $ b $ .
為了解決這個問題，客戶端現在計算承諾 $ C’’=sG+H_{252}(s)H $ .
$ H_{252}(\texttt{input}) $ 表示使用加密安全散列對輸入進行散列，並返回 252 位標量作為輸出。
客戶創建一個證明 $ C’’ $ 是對相同價值的承諾 $ s $ 作為 $ C’ $ . 該證明將允許伺服器接受 $ H_{128}(C’’) $ 作為標識符，因為它知道它基於相同的值 $ C’ $ ，它本身是基於伺服器的熵 $ e’ $ .
這是通過提供簽名來實現的 $ \sigma $ （例如簡單的 Schnorr 簽名）證明知道私鑰 $ (H_{252}(s)-b)\ mod\ \ell $ 對於公鑰 $ C’’-C’ $ 在基點上 $ H $ .
此簽名證明承諾具有相同價值的原因是，除非 $ C’’-C’ $ 導致值 $ G $ 相互抵消，離散對數 $ C’’-C’ $ 寫 $ H $ 是不可知的。
客戶端發送 $ C’’ $ 和 $ \sigma $ 到伺服器。
伺服器驗證簽名，然後在其數據庫中記錄該標識符 $ H_{128}(C’’) $ 將被允許。
客戶端現在只需要記住種子 $ s $ ，這將是用於訪問加密資源的 URL 的雜湊部分。客戶端將重建標識符 $ H_{128}(sG+H_{252}(s)H) $ , 並將使用派生自的對稱密鑰加密數據 $ s $ （使用派生技術，例如 HKDF-extract）。
似乎 zk-SNARK 可以用來實現這樣的方案。首先，簡單地使用加密雜湊 H 導出密鑰：
S = H(E||E') truncated to 128 bit I = H(S)然後，使用 zk-SNARK 來證明給定的 E 和 I，
I = H(H(E||E') truncated to 128 bit)而不會洩漏 E’。這個雙重雜湊證明是 bellman 的主要範例（使用 SHA-256）：https ://docs.rs/bellman/latest/bellman/index.html剩下的挑戰：
- 在 bellman 範例中，原像是完全可變的。對於這個案例，需要預設包含 E 的原像部分。bellman 的 blake2s gadget 支持固定的個性化，可以用來設置 E，雖然 64 位的熵比較低。
- 該範例不會將中間散列截斷為 128 位。
- zk-SNARK 需要一個可信的設置，這太昂貴了。在這種情況下，證明僅適用於伺服器。伺服器可以只宣布客戶端用於證明的隨機數據嗎？或者這個解決方案會增加攻擊面嗎？
- 計算證明本身需要 2 秒（在 WebAssembly 或更慢的機器上可能更多），這是可以接受的，但最終使用者會注意到改進。還有其他雜湊函式在基於 MiMC 的 zk-SNARK 中表現更好。但是，這些散列是否適合（足夠安全）用於密鑰派生？