Blowfish 加密解密

Blowfish 的適用定位

Blowfish 是 1990 年代設計的對稱式分組密碼，本頁可使用相同金鑰進行加密與解密，並調整 CBC、ECB、CFB、OFB 模式、填充方式、金鑰與 IV。它比較適合重現舊系統資料、檢查既有介面參數或進行教學測試，不應包裝成新系統的首選安全方案。

Blowfish 的分組長度只有 64 位元。處理大量資料時，較小的分組空間會增加重複區塊相關風險；新專案應優先採用具有認證功能的現代方案，例如 AES-GCM，並交由成熟的安全函式庫管理 nonce、驗證標籤與金鑰。

模式、填充與 IV 必須一致

CBC、CFB 和 OFB 需要 IV，解密時必須使用與加密相同的 IV、模式、填充和金鑰。ECB 不使用 IV，但相同明文區塊會產生相同密文模式，因此不建議用於真實敏感資料。不同程式庫即使都寫 Blowfish，只要參數或資料格式不同也無法互解。

PKCS7、ZeroPadding、NoPadding、ISO10126 和 ANSI X9.23 對尾端位元組的處理方式不同。選擇 NoPadding 時，輸入長度必須符合分組要求；文字編碼和 Base64/Hex 只是資料表示法，不會提高演算法安全性。

如何完成一次相容性測試

1. 先向來源系統確認模式、填充、金鑰長度、IV 和字元編碼。
2. 選擇加密，輸入去識別化測試文字與測試金鑰。
3. 依規格設定模式與 IV，取得 Base64 或 Hex 密文。
4. 切換解密，保留相同參數並貼回完整密文。
5. 比對還原文字及另一端程式庫的結果。

測試向量應記錄全部參數，不能只保存一段密文。像 U2FsdGVkX18= 只表示 OpenSSL salted 格式的前綴片段，不是可驗證的完整 Blowfish 密文。

金鑰與輸出格式

金鑰可以用文字、Hex 或 Base64 表示。文字金鑰會先依字元編碼轉成位元組，同一個肉眼可見字串在不同正規化或編碼下可能產生不同結果。Hex 必須由完整位元組組成，Base64 則需要合法填充；不要把十六進位文字誤當作一般文字輸入。

長金鑰不會消除 64 位元分組的結構限制，也不能補上驗證標籤。若接收端需要判斷密文是否遭修改，應另外使用正確的驗證機制；不要把「能夠解密」誤當作完整性驗證成功。

安全與隱私界線

頁面運算由瀏覽器中的密碼函式庫執行，但仍不應貼上正式密鑰、密碼、客戶資料或未公開文件。瀏覽器擴充功能、剪貼簿紀錄、螢幕分享與共用裝置都可能造成額外風險。正式系統的金鑰應存放在受控的金鑰管理服務或安全硬體中。

若目的是密碼儲存，請使用 Argon2、scrypt 或 bcrypt；若是新應用資料加密，優先選擇 AES-GCM 或 ChaCha20-Poly1305。Blowfish 頁面只適合用於相容性測試與學習。

常見問題

為什麼解密是亂碼？先核對金鑰、IV、模式、填充、輸入格式和原文字元編碼。

Base64 是加密嗎？不是，Base64 只是可逆編碼。

新專案可以使用 Blowfish 嗎？不建議，請優先選擇有認證加密能力的現代演算法。

可以解密不知道金鑰的資料嗎？不可以，本工具不破解或猜測金鑰。