DES / 3DES / RC4 / Blowfish 加密與解密

用四種至今仍藏在舊檔案、舊備份和舊協議裡的經典密碼進行加密或解密 —— DES 與 3DES 支援 ECB/CBC，RC4（ARCFOUR）為流密碼，Blowfish 金鑰最長 56 位元組。已用 FIPS 46-3、Schneier 公開的 Blowfish 向量和 RFC 6229 校驗。全部在你的瀏覽器本地執行 —— 不上傳任何資料。新專案請改用 AES 加密 / 解密。
這些演算法僅為相容舊資料而保留，不應用於新專案。 DES 於 2005 年被撤銷，3DES 於 2023 年被停用，RC4 自 2015 年起被 TLS 明令禁止（RFC 7465），而 Blowfish 的 64 位分組在同一金鑰下處理約 32 GiB 資料後就會觸及生日邊界。任何新用途都請改用 AES 加密 / 解密。
方向： 演算法： 模式： 輸出：
DES = 1977 年的資料加密標準：64 位分組，有效金鑰 56 位。雖已撤銷，仍見於舊備份、PIN 塊（銀行）和 Kerberos v4。金鑰必須正好 8 位元組。
金鑰 (8 bytes, hex or text)
十六進位制允許空格、冒號和 0x 字首。DES 會忽略每個金鑰位元組的奇偶校驗位。
Plaintext text (the data to encrypt, UTF-8 encoded)
分組密碼使用 PKCS#7 填充；RC4 從不填充。
密文 (一行內容：演算法、模式、結果；引數在下面幾行)
本頁接受的金鑰長度
演算法金鑰分組狀態
DES正好 8 位元組（有效 56 位）64 位2005 年撤銷（NIST SP 800-131A）
3DES-EDE3正好 24 位元組（有效 112 位）64 位2023 年後不允許使用（SP 800-131A r2）
3DES-EDE2正好 16 位元組（有效 112 位）64 位同 EDE3，更弱的舊選項
RC4 / ARCFOUR1..256 位元組流2015 年起 TLS 停用（RFC 7465）
Blowfish4..56 位元組64 位未被攻破但受 64 位分組限制；建議用 Twofish/AES
有效金鑰長度小於原始長度，是因為 DES 把每個位元組的一位用作奇偶校驗：64 位原始金鑰只含 56 個金鑰位，而三獨立金鑰的 3DES 有效強度為 112 位（中間相遇攻擊）。
與 OpenSSL 互操作 —— OpenSSL 3 已把這些演算法移入 legacy provider；若你的版本拒絕使用，請加上 -provider legacy。與本頁等價的命令列：
openssl enc -des-ecb -K 133457799BBCDFF1 -in msg.bin -out msg.enc
openssl enc -des3 -K <48 hex> -iv <16 hex> -in msg.bin -out msg.enc（3DES-CBC）
openssl enc -rc4 -K 4b6579 -in msg.bin -out msg.enc / -bf-cbc 用於 Blowfish-CBC。
解密加 -d。-K 接受原始十六進位制金鑰，-k 接受口令（不要用它 —— 其 KDF 與本頁任何演算法都不同）。
自檢
用公開向量和獨立生成的向量重跑本頁引擎：FIPS 46-3 的 DES 算例、OpenSSL 生成的 3DES EDE2/EDE3 密文、Schneier 的 Blowfish 向量、RFC 6229 的 RC4 測試向量以及經典的“Key/Plaintext”示例，每種模式的往返測試，以及反向測試（金鑰長度錯誤、密文長度不是分組整數倍必須失敗）。不會向任何地方傳送資料。
從零講清 DES、3DES、RC4 與 Blowfish
一句話：這四種密碼是 1990 年代的主力 —— DES 及其三重加密的權宜之計 3DES、流密碼 RC4，以及 Blowfish —— 如今它們全部退役或被廢棄，只因舊檔案、舊硬體和舊協議仍需讀取才得以存活。
DES：1977 年的標準，一切的起點

它是什麼。資料加密標準（FIPS 46，1977）是對 64 位分組進行 16 輪 Feistel 運算的密碼，金鑰 56 位（因每位元組有一位用於奇偶校驗，故存為 8 位元組）。它由 IBM 設計、NSA 參與，作為美國標準使用了二十年；1998 年 EFF 的 Deep Crack 機器用 25 萬美元的硬體在 56 小時內暴力破解了一個金鑰，它由此在政策層面被判死刑。NIST 於 2005 年撤銷了它的加密用途。

為什麼奇偶位會讓金鑰長度的說法混亂。DES 金鑰的每第 8 位都由其餘七位算出，因此 8 位元組金鑰只含 56 個獨立位 —— 這就是同一個演算法既被稱作“64 位金鑰”又被稱作“56 位金鑰”的原因。3DES 繼承了這一點：24 個原始位元組 = 168 原始位 = 112 有效位（餘下的被中間相遇攻擊抵消）。

如今在哪裡還會遇到它。銀行 PIN 塊（ISO 9564）、部分 Kerberos v4 域、舊備份歸檔和智慧卡。如果一個系統今天仍要求用 DES，那麼它要麼是在與 1990 年代的硬體互通，要麼就是不安全的。

3DES：加密、解密、再加密

它的手法。三重 DES 對每個分組跑三遍 DES：EDE3 用三個不同金鑰（C = Ek3(Dk2(Ek1(P)))）；中間那一步是解密，這樣只要令 k1=k2，3DES 實現就能模擬單重 DES。EDE2 只用兩個金鑰（k1=k3），有效強度 112 位。這個構造是個權宜之計：不必發明新演算法，就把一個已被攻擊的演算法的安全性提高了三倍。

它終究還是消亡的原因。兩個問題：它慢（每個分組三遍完整 DES，約為 AES 速度的 1/20），而且沿用了 64 位分組。當同一金鑰下處理 32 GiB 資料（即 232 個分組的生日邊界）時，分組碰撞頻繁到足以洩露明文結構 —— 2016 年的 Sweet32 攻擊就在 TLS 的 3DES 會話上演示了這一點。NIST 自 2023 年起不允許再用 3DES 加密（SP 800-131A r2）；PCI DSS 要求支付系統停用 3DES。

RC4 / ARCFOUR：早期 Web 的流密碼

它如何工作。RC4（Ron's Code 4，1987 年設計，1994 年洩露）是流密碼：金鑰先排程出一個 256 位元組的置換（KSA），隨後該置換輸出偽隨機位元組流（PRGA）與訊息異或。沒有填充、沒有分組長度限制、任意訊息長度、軟體實現極快 —— 這正是它在 1990 年代統治 SSL/TLS 和 WEP 的原因。“ARCFOUR”是多數開源專案為避免商標問題而使用的名字。

它是怎麼被攻破的。Fluhrer-Mantin-Shamir（2001）指出金鑰流的前若干位元組存在偏差 —— 這對 WEP 是致命的，因為 WEP 的每包金鑰構造恰好把這些位元組送到攻擊者面前。後來的偏差攻擊（2013 年，AlFardan 等人）通過數百萬次連線從 RC4 保護的 TLS 會話中恢復了明文。RFC 7465（2015）徹底禁止在 TLS 中使用 RC4。

經典測試向量。金鑰“Key”（3 位元組）、訊息“Plaintext”得到密文 bbf316e8d940af0ad3 —— 可點 RC4 示例對比。本頁自檢還校驗 RFC 6229 中 40 位金鑰 01 02 03 04 05 的金鑰流：b2396305f03dc027ccc3524a0a1118a8。

Blowfish：未被攻破，但受分組長度限制

它是什麼。Bruce Schneier 1993 年的 Feistel 密碼：64 位分組，金鑰 32 至 448 位（4..56 位元組），16 輪，以及一個著名的金鑰排程 —— 它把 Blowfish 本身執行 521 次來生成子金鑰，這使得金鑰初始化很慢，但暴力破解的代價同樣很高。目前沒有實用的密碼分析能攻破完整輪數的 Blowfish。

那它為什麼還在這頁上。問題在 64 位分組，而不在演算法本身：同一金鑰下超過約 32 GiB 後，生日碰撞就會洩露資料（與 3DES 相同的邊界，Sweet32 式攻擊）。Schneier 本人建議任何新用途都改用他的後繼者 Twofish（AES 決賽演算法）或 AES。Blowfish 仍活在 bcrypt 內部 —— 那個口令雜湊的金鑰排程就是 Blowfish —— 這沒問題，因為雜湊處理的輸入極小，不涉及 GB 級資料。

經典測試向量。全零金鑰加密全零明文得到 4ef997456198dd78（示例輸出的首個分組）；金鑰“abcdefghijklmnopqrstuvwxyz”加密“BLOWFISH”得到 324ed0fef413a203。兩者都出自 Schneier 公開的向量檔案，並由本頁自檢校驗。

常見錯誤
  • 用它們加密新資料。除 Blowfish（受分組長度限制）外，本頁每種演算法都已被廢棄。正確的現代選擇是 AES-GCM —— 參見 AES 加密/解密。
  • 用口令當 DES 金鑰。8 個字元的口令並不是 56 個隨機位，每個字元只有幾個位元的熵。老系統正是這麼做的，這也是“DES 加密”的歸檔檔案幾分鐘內就被字典攻破的最常見原因。
  • 在 CBC 模式複用 IV。同一金鑰下，首塊會洩露不同訊息之間明文是否相等。“隨機 IV”按鈕不是擺設。
  • 複用 RC4 金鑰流。RC4 對同一金鑰產生相同的金鑰流：用一把金鑰加密兩條訊息等於兩次一密 —— 把兩段密文異或，兩段明文就都出來了。WEP 的致命缺陷正是這種金鑰流複用構造。
  • 以為“能解密就是對的”。這裡的 ECB/CBC 在解密時只校驗填充 —— 金鑰錯誤時通常解出一堆亂碼，但仍可能碰巧通過填充檢查。任何傳統模式都沒有完整性校驗；如果你需要，應該選 AES-GCM，而不是這些演算法。
  • 把 3DES 當成“168 位”。原始金鑰是 168 位，但有效強度只有 112 位 —— 中間相遇攻擊把三重加密降到略高於兩重的水平，正如它對 3DES 的前身構造所做的那樣。
常見問題

既然演算法已破，為什麼還保留這個工具？為了相容。加密過的備份、匯出的舊格式檔案、抓取的協議報文、CTF 題目，以及無法升級的硬體，都還在說這些演算法。讀取舊資料是正當的，用它們寫新資料則不是。

我的 DES 金鑰奇偶位不對 / 含非 ASCII 位元組。DES 會忽略每個金鑰位元組的奇偶位，因此有效金鑰始終是其餘 56 位。本頁接受任意 8 位元組，不強制偶校驗。

為什麼解密出來的文本有時像亂碼？金鑰錯、模式錯、IV 錯，或者資料的加密方式與你設想的不同。沒有認證標籤就沒有乾淨的“金鑰錯誤”提示 —— 填充校驗是唯一的線索，而且它有可能碰巧通過（約 1/256 的機率）。

Blowfish 對我的檔案安全嗎？小檔案在密碼學意義上是安全的（沒有實用攻擊）。但同一金鑰下處理 GB 級資料就不行 —— 64 位分組的生日邊界取決於資料量，而非金鑰強度。用 Twofish 或 AES 可以避開這個問題。

我在別處看到的 72 位元組 Blowfish 金鑰是怎麼回事？有些實現最多接受 72 位元組，但 Schneier 的參考實現用 56 位元組，而且在標準金鑰排程下，超出部分的位元組不會帶來額外的擴散。本頁遵循參考實現：4..56 位元組。