河豚填充物

我目前正在對使用 Blowfish 的二進製文件進行逆向工程。範例輸入將是：

08 00 01 00 1C FB 19 00

當此數據被加密然後解密時，我得到以下結果：

encrypt: 47 D2 23 7A 57 2B 9F B0 3F B5 1E BE C6 66 54 0C
decrypt: 08 00 01 00 1C FB 19 00 94 14 EC 29 EE 4E 06 00

我對如何在此處添加填充感到困惑。多件事：

• 為什麼首先有填充（第二塊），當輸入是 8 個字節時，這是河豚塊的大小？
• 使用 6 個字節的填充似乎是任意的，為什麼 0x06 不在沒有空字元的最後一個字節上？

我查看了不同類型的加密填充，但似乎沒有一個真正匹配。

也許這與分組密碼的操作模式有關？

我已經嘗試了幾個河豚實現，但到目前為止它們似乎並不匹配。

這對任何人來說都很熟悉嗎？

編輯：

我被問到為什麼我認為這是一個填充。好吧，二進製文件執行以下操作：

0063A1E5  |.  66:8B4C28 FE  MOV CX,WORD PTR DS:[EAX+EBP-2]
0063A1EA  |.  66:83F9 08    CMP CX,8
0063A1EE  |. /76 04         JBE SHORT <some address>
0063A1F0  |. |33C0          XOR EAX,EAX
0063A1F2  |. |5D            POP EBP
0063A1F3  |. |C3            RETN

因此，當這個空頭大於或等於 8（塊大小）時，它就會放棄。

當您考慮以下內容時，這也很有意義：

[[08 00] 01 00 1C FB 19 00] [94 14 EC 29 EE 4E] [06 00]
   ^         ^                      ^             ^
data size    |                    padding     pad size
         data block               6 bytes!

這看起來像是一種相當愚蠢的專有填充方法，它使用 16 位小端編碼 - 與基於 x86 的 CPU 一樣。

它似乎用隨機填充填充其餘部分，可能是為了嘗試使用填充 Oracle 攻擊來避免洩漏資訊。

檢查大小不大於 8 是個好主意，否則錯誤的密文可能會刪除比明文中更多的字節。如果最後一個部分明文塊是 7 個字節，則程式碼會出現問題，因為填充使用兩個字節並且不適合。

可能程式碼首先假定靜態大小的數據包，因此加密和解密不會嚴重失敗。

---

鑑於問題中的資訊，我不確定我們能說的比這多得多。程式碼很爛，但如果它仍然部署 Blowfish，這是可以預料的——作者本人不再推薦的密碼。

引用自：https://crypto.stackexchange.com/questions/63162