在 ECB 模式下使用 DES 重新排序非塊對齊部分
我得到了一個在 ECB 模式下使用 DES 加密的密文文件。已知加密後的明文格式如下：
每行文本都包含一個工資單，後跟一個名稱（無空格）：
- 名稱 32 個字元；
- 支付金額8個字元；
- 1 個換行符。
一個範例純文字文件將是：
abcdefghikabcdefghikabcdefghikab00000000 abcdefghikabcdefghikabcdefghikab10010010 abcdefghikabcdefghikabcdefghikab10010010 abcdefghikabcdefghikabcdefghikab10010010 abcdefghikabcdefghikabcdefghikab10010010 abcdefghikabcdefghikabcdefghikab10010010 abcdefghikabcdefghikabcdefghikab11111111並且它是使用這個命令加密的（當然沒有給出密鑰，原因很明顯）：
openssl enc -e -des-ecb -nosalt -in plaintext.txt -out ciphertext.enc密文文件大小為 288 字節，因為有 6 個換行符 (
'\n') 字元，並且 DES 以 64 位塊進行加密，很容易看出此工資單中有 7 個條目。**目標：**將第一行與最後一行交換。
如果所有條目都在一條沒有空格的行上，這將是一項簡單的任務，因為在 ECB 模式下，您可以在 64 位塊中移動而不會被檢測到。我要做的就是取前 40 個字節並與最後 40 個字節交換它們。但是，由於
'\n'每行末尾都有一個字元，因此這種方法不起作用。我覺得有點卡住了。我正在尋找的只是一個正確方向的點。
如果明文格式確實如您所描述的那樣，那麼您就不走運了：換行符的插入和隨之而來的明文記錄的移動足以破壞密文中的任何結構。如果明文較長，例如 8 條記錄，那麼它可以工作，但是只有 7 條記錄，無法簡單地通過改組密文塊來切換第一個和最後一個記錄。
但是，我懷疑您誤解了明文中是否存在換行符。具體來說，由於您給出的加密命令不包含該
-nopad選項，因此該openssl enc命令在加密之前將PKCS #5/7 填充應用於明文。為了明確可逆，這種填充方案總是將明文的長度增加至少一個字節 - 特別是，它會導致 280 到 287 字節之間的任何明文長度（包括 280 和 287 字節）產生 288 字節的密文。因此，我懷疑您的數據實際上沒有換行符，僅包含 7 個 40 字節的固定長度記錄以及 8 個字節的填充。將密文的最後 8 個字節保留在原位，並切換其前面密文的第一個和最後一個 40 字節塊，應該可以解決問題。
好吧，DES 很弱，因為您可以猜測明文，您可以使用彩虹表來破解密鑰，然後當然可以解密並重新加密消息。
除此之外，如果您真的想執行此特定操作，我認為您不能重新排序塊以更改第一行和最後一行。