Diffie-Hellman：素數模數的大小是否取決於秘密的潛在大小？
我正在編寫自己的密碼系統，使用 One Time Pad 和 Diffie-Hellman 為 OTP 生成密鑰。我在伺服器端使用 Rails，在客戶端使用 Javascript。
請不要告訴我這是不安全的，我不應該這樣做。我這樣做純粹是為了教育目的，絕不會在非實驗意義上進行部署。
由於這是 OTP，我需要一個至少與被加密的消息一樣長的密鑰流。根據我的閱讀，DH 似乎需要一個大得離譜的安全素數模數。或者是嗎？
每個字元都需要一個不同的隨機密鑰，因此對於 10 個字元長的字元串，DH 密鑰交換需要發生 10 次才能為該字元串創建一個公共密鑰數組。
但是，我似乎得到的整數可能比必要的大得多。
假設使用者製作了一個私鑰數組：
var userPrivateKeys = [9,12,0,23,7,8,4,7,15,24]還有一個 2048 位安全素數模數，以 2 作為生成器：
var prime = 32317006071311007300338913926423828248817941241140239112842009751400741706634354222619689417363569347117901737909704191754605873209195028853758986185622153212175412514901774520270235796078236248884246189477587641105928646099411723245426622522193230540919037680524235519125679715870117001058055877651038861847280257976054903569732561526167081339361799541336476559160368317896729073178384589680639671900977202194168647225871031411336429319536193471636533209717077448227988588565369208645296636077250268955505928362751121174096972998068410554359584866583291642136218231078990999448652468262416972035911852507045361090559 var generator = 2使用者的共享密鑰數組最終看起來像這樣：
var userPublicKeys = [512,4096,1,8388608,128,256,16,128,32768,16777216]在使用者和伺服器交換他們的公鑰後，我們得到這個作為公共密鑰：
var commonKeys = [134217728,2.2300745198530623e+43,1,1.725436586697641e+69,72057594037927940,16777216,17592186044416,1.78405961588245e+44,6.216540455122333e+85,1]聖….
這些整數遠大於字母表的模數，甚至是 ASCII 的模數。
我
$$ think I $$了解在創建要在 AES 等密碼中使用的密鑰的上下文中，素數模數必須很大，但是在 OTP 中的每個字元都有不同的隨機密鑰的上下文中呢？ 例如，假設我的消息僅包含字母 a 到 z，並且我的模數較小：
p = 27 g = 3 userPrivateKeys = [9,12,0,23,7,8,4,7,15,24]我們的算法是：
2^a mod 27或在 Javascript 中…
Math.pow(2, a) % 27我們將生成一個公鑰列表：
userPublicKeys = [26,19,1,5,20,13,16,20,17,10]這樣更易於管理。
那麼在這種情況下，素數模數這麼小有問題嗎？
據我所知，打破這一點的唯一方法是通過詳盡的搜尋。由於 OTP cryptext 不包含有關原始消息的資訊，因此無法進行詳盡的搜尋。我已經閱讀了其他可能的方法來打破這個和一般的 DH，但通常我不理解它們，或者它們依賴於已知的秘密之一。
那麼我有什麼遺漏嗎？
好吧，一方面，您沒有使用“One Time Pad”。根據定義，“One Time Pad”意味著某人使用真正的隨機性（而不是算法）生成一個數字墊，並且沒有潛在的對手知道該墊可能包含的任何資訊。然後，將那個 pad 給發送者和接收者，然後發送者用它來偽裝明文，這樣接收者（有 pad）可以恢復明文，但是對手沒有pad 沒有得到關於明文的資訊（因為有了密文和任何潛在的明文，就有一個可能的 pad 使這成為可能，而對手無法確定哪個潛在的 pad 更有可能。
相反，您正在執行一系列 Diffie-Hellman 操作來生成共享機密，然後使用這些共享機密執行流加密。
這就是為什麼區分很重要的原因；你說：
打破這種情況的唯一方法是通過詳盡的搜尋；因為 OTP cryptext 不包含有關原始消息的資訊
如果您使用的是 OTP，這確實是真的；除了密文，攻擊者實際上沒有任何資訊，而密文確實不會透露任何關於明文的資訊。但是，密文並不是發送方和接收方唯一交換的內容，您之前提到過：
使用者和伺服器交換他們的公鑰
也就是說，攻擊者除了可以使用的密文之外，還有可用的資訊。也就是說，除了資訊安全（OTP 是），你還希望攻擊者不能使用公鑰來恢復共享密鑰（pads），也就是說，你希望恢復共享密鑰的問題也一樣攻擊者很難。換句話說，你希望你在計算上是安全的。
在這裡，在這種情況下，當你問：
素數模數這麼小有問題嗎？
您要問的問題是“即使模數很小，Diffie-Hellman 在計算上是否安全”。答案是“不，不是”。對於 MODP 組（您正在使用的組），似乎 DH 可以被破壞，除非模數至少為 800 位（實際上，針對該大小的模數的攻擊實際上並沒有被證明，但是已經有針對相關的攻擊原語，我們相信這些攻擊可以轉化為針對 Diffie-Hellman 的攻擊）。
還有其他組可以做得更小，但仍然被認為是安全的（例如，即使曲線只有 200 位左右，橢圓曲線組也可能非常安全）；但是，您不會接近“ASCII 值”。
當我們像這樣使用 Diffie-Hellman 時，我們通常做的是執行單個 Diffie-Hellman 操作以生成單個（大）共享密鑰，然後將該共享密鑰提供給Key Derivation Function；然後可以將該 KDF 的輸出呈現給Stream Cipher，然後將其輸出用於實際加密數據