RSA-KEM：最小隨機位數
我已經問過一些關於 RSA-KEM 的問題 - 尚未正式回答 - 關於使用公鑰加密的輸入秘密here和（關於這個問題的主題較少）here。
CodesInChaos 已經在連結到的第一個問題中發表了評論。在生成隨機值期間將最高有效位設置為零似乎是合乎邏輯的 $ z $ 不要對安全造成太大影響。
儘管如此，對大量數據使用隨機數生成器可能是操作模式的一個缺點，尤其是當它們需要為單個 RSA 操作生成 4096 位隨機性時。如果所述隨機數生成器很慢或者如果隨機數生成器可用的熵不足，這可能是一個問題。
我的相關問題是：
- 我們能否在不降低 RSA 操作安全性的情況下進一步減少 KDF 的輸入密鑰材料數量？如果是，多少？
- 如果是，是否需要良好的隨機位分佈（一半在左邊，一半在右邊？）
- 如果不是，我們是否可以在檢索到安全密鑰派生所需的位數後使用單向原語，例如 XOF 或 MGF-1，並將其提供給 RSA-KEM？
或者如果我遇到快速 DRBG 不可用的情況，我應該逃跑並使用 RSA OAEP 嗎？
理論上的擔憂。 RSA-KEM 對 RSA 問題的標準安全縮減依賴於解密預言機處理大部分輸入空間的能力。如果您沒有將所有位都輸入到 KDF 中，或者如果您對某些輸入進行等效處理，您可能會自責，例如無法驗證 OAEP 中的 lHash。
實際關注。 如果您不生成元素的所有位 $ x \in \mathbb Z/n\mathbb Z $ 您從中派生密鑰 $ k = H(x) $ ，即使您將它們分散開，以使標準實數立方根攻擊對指數不起作用 $ e = 3 $ ，您可能仍然一頭扎進了富蘭克林-賴特相關消息攻擊，它甚至適用於指數 $ e = 65537 $ 每個人都在沒有 PTSD 的情況下悄悄接受 $ e = 3 $ 從 90 年代密碼學工程的黑暗時代遺留下來。
性能問題。 在現代 AMD CPU 上計算最多花費大約 20k 個週期 $ x^3 \bmod n $ 對於 2048 位 $ n $ — RSA 中較快的一半，具有最快的指數；任何其他指數都較慢（可能在拉賓領域除外），並且解密要慢得多。使用樸素的 C 程式碼使用 Salsa20 生成 2048 位的最壞情況約為 1k 週期，這是最簡單的選擇，而不是最便宜的選擇。
OAEP 還需要生成關於 $ \lg n $ 位數據，但通常使用更昂貴的 PRNG (‘MGF’)，例如 SHA-256。什麼情況下可以產生 $ x $ 是瓶頸，但不是 OAEP 的 MGF 計算？