XOR & SHIFT 的完美保密？
我讀過當密鑰完全隨機時，XOR 提供了完美的保密性。然而，在技術上很難生成真正的隨機數，尤其是在電腦上，這就是人們使用 AES、Twofish 和其他密碼的原因。
所以使用 XOR 的條件是密鑰必須是真正隨機的，並且密鑰大小必須至少與消息一樣大。
如果我們只使用一個很長的密鑰來保證至少與消息大小一樣多的熵呢？
例如，我們需要加密 6 位消息，然後使用 32 位偽隨機密鑰，其中應該至少有 6 位熵。或者甚至使用 512 位密鑰，如果 RNG 很弱，以滿足我們的需要。然後我們對前 6 位進行異或。
現在其他 26 位正在洩漏，但如果攻擊者不知道輸入消息的大小，那麼應該沒有問題。
但是如果攻擊者確實知道輸入的大小，那麼我們也會將輸出位從右向左移動一個
n瓦片，p在它們之間留出空間。喜歡這個：
顯然，n 和 p 值也是我們選擇的隨機和秘密。所以我們只需要保守秘密
XOR key。n``p在 1 個班次操作之後，該消息應該是完全保密的。XOR 已經提供了完美的保密性，但移位操作也隱藏了大海撈針。
因為如果攻擊者甚至不知道我們使用的是什麼密碼，他怎麼能暴力破解原始輸入。所以我在這裡建議隨機化密碼參數。
你怎麼看，這是一個可行的加密系統嗎？
提出的方法存在一些問題：
或者甚至使用 512 位密鑰，如果 RNG 很弱，以滿足我們的需要。
如果你的 RNG 壞了，那麼使用更多它也無濟於事。
“如果攻擊者知道一些事情，那麼我們就會做其他事情”
正如@tylo 在評論中提到的那樣：“……（那個想法）存在根本缺陷：你不能讓加密適應對手所做或知道的事情。”
詳細說明原因：
- 你怎麼知道某個特定的對手知道或不知道什麼？
- 假設您確實知道某個特定對手知道/不知道什麼，您將如何確保他們收到您為他們設計和打包的算法的正確版本？
- 除此之外，您將如何防止他們獲得軟體的“較弱”副本，這些副本旨在用於知識較少的對手？
為了防止最壞的情況發生，我們必須假設最壞的情況。這意味著我們需要假設對手已經知道除了密鑰之外的所有內容。
因為如果攻擊者甚至不知道我們使用的是什麼密碼，他怎麼能暴力破解原始輸入。所以隨機化密碼參數是我在這裡的建議
正如@Elias 在回答中提到的那樣：保守密碼實際上是一個糟糕的策略，這是一個已經被一次又一次證明的教訓。
問題是您無法擺脫對保密的需求，這意味著您無法擺脫對密鑰的需求。將密碼算法保密意味著使用算法本身作為密鑰。對算法保密要比對小塊隨機數據保密要困難得多：每個要加密/解密的人都知道該算法，這增加了每個參與者洩露的可能性。
“但如果我是唯一一個使用它的人怎麼辦？問題解決了，對吧？”
假設您只打算使用您自己的秘密算法加密/解密消息：如果算法是密鑰，那麼您只需將密鑰發佈到網上供所有人查看和評論（以及分析和攻擊）。
隨機化密碼參數和保密密碼不是一回事：我實際上不會將您的設計描述為保密密碼（特別是考慮到它是如何發佈在這裡供所有人查看的）。
異或和轉置被破壞
如果我們只使用一個很長的密鑰來保證至少與消息大小一樣多的熵呢？
這是一個可行的加密系統嗎？
如果您碰巧加密的消息位較少，那麼您有密鑰位，那麼是的；但這只是因為它實際上等同於基本的一次性便箋簿，因此不是一個現實的答案。
否則，對於更實際的案例，不：xor-with-key + transposition 總是被破壞，即使轉置也是一個秘密。問題源於方程的次數沒有增加。表示輸出的表達式將只包含一些輸入項的 XOR。秘密轉置僅用於改變構成每個輸出位的項。
通過首先送出一個全為 0 的塊進行加密來破壞這種設計通常是微不足道的：生成的密文將只包含密鑰位。秘密轉置不會解決這個問題，它只會修改哪些關鍵位構成每個輸出位。
獲得 XOR 密鑰後，您可以通過送出權重為 1 的明文（即 1、2、4、8 等）的加密來計算轉置密鑰。從每個這樣的密文中刪除 XOR 密鑰後，結果將顯示哪些輸出位包含相關的明文輸入位。如果密碼的塊大小為 n 位，那麼這種攻擊只需要 n 個選擇的明文即可完全恢復兩個密鑰的每一位。
似乎您正在嘗試使用密碼的密鑰計劃作為密碼的一種操作模式（操作模式通常負責確保後續塊以不同方式加密）。如果是這樣，最好將這兩個任務分開。