將下一個隨機的 One Time Pad 作為編碼消息的一部分？
我在這裡嘗試做一些非常簡單的事情，即使用一次性密碼 (OTP) 加密消息，並將下一個 OTP 作為同一加密消息的一部分。即第一條消息由消息的實際文本組成，然後將下一個 OTP 添加到末尾。OTP 的長度應該始終保持不變，所以我做了一些簡單的位操作，將多個字元壓縮到一個字節中。這意味著每個連續的 OTP 都將與原始 OTP 的長度相同。
我的主要問題：下一個 OTP 包含在每個編碼消息的已知位置這一事實是否是允許在給定一些加密消息的情況下解密消息的因素？還是會像普通的 OTP 一樣安全？
下一個 OTP 包含在每個編碼消息的已知位置這一事實是否是允許在給定一些加密消息的情況下解密消息的因素？還是會像普通的 OTP 一樣安全？
是的，這是個大問題。
您實際上是在公開傳輸您在密文末尾添加的（下一個）OTP。換一種說法：您正在共享（下一個）秘密，不受保護，並且在任何潛在攻擊者的視線範圍內。
當假設我們——正如我們通常所做的——尊重Kerckhoffs 的原則時，這一點尤其正確。攻擊者會知道您正在將下一個 OTP 添加到目前密文的末尾，因此可以輕鬆提取下一個秘密。
即使我們不尊重 Kerckhoffs 的原則並為您的構造保密，對於僅截獲 2 次傳輸的攻擊者來說，掌握您在做什麼也不會太難……其中包括攻擊者還獲得了成為能夠簡單地解密第二條截獲的消息，並且還可以了解您將用於傳輸編號 3 的下一個 OTP。這絕對不是您想要的……
OTP 安全聲明
您有點違反OTP 的定義（第 2 點、第 3 點，也許還有第 4 點）：
根據定義，OTP 要求“密鑰”是……
- 一個真正隨機的一次性填充值，
- 以安全的方式生成和交換。
- 至少與消息一樣長，並且
- 只能使用一次。
如果您的想法另外違反了第 4 點，我會留給個人意見，因為這在一定程度上取決於個人觀點。雖然其他人可能不同意，但我個人認為可能會被解釋為重用。
最後，這並不重要，因為違反第 2 點和第 3 點已經足以說明通常的 OTP 安全聲明在查看您的構造時根本不適用。
與您的施工有關的其他問題
請注意，我們尚未討論潛在的身份驗證問題——例如：您需要考慮攻擊者攔截您的消息、修改它們，然後在您無法檢測到修改的情況下轉發它們。在大多數情況下，這是災難性的。事實上，OTP 本身並不處理身份驗證……這就是 MAC 的用武之地。
TL;博士：
- 永遠不要以不受保護的方式共享/傳輸秘密（這裡：下一個密鑰）。
- 始終考慮身份驗證，因為簡單地加密某些東西並不意味著它不會被偽造。您應該——至少——能夠檢測到消息偽造。
編輯
此編輯包括發佈到此答案的評論，以使答案更加完整併保護包含的資訊，以便在清理評論（也稱為刪除）時它們不會消失。
**OP：**嗨，e-sushi，謝謝您的詳細回答。我想也許你是誤會了。我沒有在密碼文本的末尾包含下一個 OTP，而是作為密碼文本的一部分。所以基本上我正在做丹尼爾描述的事情：“……用隨機數據填充消息的末端，加密（消息+隨機），然後解密並在最後收集隨機數據，然後將其用作另一個一次性填充……”。當然，第一個 pad 將以安全的方式交換，所有後續的“壓縮”pad 將與消息的長度相同。是的，仍然會到達 MAC thx :-)
**我：**同樣的問題……因為您正在將下一個 OTP 包含在目前消息中。因此，將消息 1 的後半部分與消息 2 的前半部分進行異或運算將顯示您包含在消息 1 中的密鑰……它允許解密消息 2 的前半部分。
**我：**最後，你遇到了先有雞還是先有蛋的問題（更好的魚塘問題）。OTP 密鑰應該是 100% 的明文長度。因此，您不能將明文添加到您的“下一個 OTP”，因為那將不再是 OTP。唯一的解決方案是您進行一些擺弄，這會重疊並歸結為雙異或…… $ (m \oplus nextOTP) \oplus currentOTP) $ . 沒有辦法創建一個 OTP $ (m | nextOTP) \oplus currentOTP $ 因為 $ nextOTP $ 和 $ currentOTP $ 必須具有相同的長度。否則，您將無法傳輸下一個 OTP。即使在最佳情況下，每次傳輸都會將可用於傳輸下一個密鑰材料的空間減半。
**OP：**啊哈，好吧，我明白了，所以它會導致與重複使用 OTP 相同的問題。哦，好吧，我想也許這是分發新墊的好方法。永遠不要扮演自己的加密角色，大聲笑。最好的方法是在消息中包含從何處獲取下一個 pad 的資訊，或者使用一本書，或者一些隨機數據流，這些數據可能是用隨機密鑰播種的。
我： @Sci 是的，這就是為什麼我在我的回答中提到“雖然其他人可能不同意，但我個人認為某些東西可能被解釋為重用。” ;) 事實上，在明文消息中包含提示（在可以找到下一個 OTP 的位置）似乎更合乎邏輯，因為它使問題無效。與向整個事物添加 MAC 以使其更安全和更完整有關——最簡單的可能是 HMAC（基於雜湊的 MAC）。請參閱我們應該 MAC-then-encrypt 還是 encrypt-then-MAC？. 添加並不難，但您需要正確執行。
編輯 2
最後但並非最不重要的是，@tylo 的評論完成了它：
我認為這個答案具有大部分要點，但有一個誤解，尚未解決：由於Kolomogorov 的複雜性，一個真正的一次性墊不能平均壓縮。並且使用“可壓縮 OTP”不會真正隨機和統一。