如果 Blowfish 沒有被破解，我們為什麼不使用它？
既然 Blowfish 是舊的、經過良好審計的並且沒有公開的攻擊，為什麼我們要使用 AES 來代替？我知道 Bruce Schneier 說 Blowfish 不安全，並告訴人們過渡到 Twofish，但為什麼呢？AES 有很多漏洞，例如 padding oracle 攻擊和功耗分析，但 Blowfish 沒有任何眾所周知的問題。Blowfish 可以獲取高達 448 位的密鑰，這比 AES 的 256 位要大。有什麼我不明白的嗎？它受到公眾監督的時間最長，問題最少。
也許是因為 Blowfish 的小塊大小？
背景：使用 Blowfish 加密少於 30 個字元的字元串是否安全？
如果 Blowfish 沒有被破解，我們為什麼不使用它？
原因眾所周知，它具有 64 位塊大小，因此容易受到生日攻擊。這是為 HTTPS 完成的，有關更多資訊，請參閱sweet32；
$$ \text{Sweet32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN} $$
使用 Blowfish 加密少於 30 個字元的字元串是否安全？如果我不將它用於 HTTP，僅用於儲存小字元串，它是否仍然不安全？
沒有問題。GnuPG推薦了 Blowfish；Blowfish 不應用於加密大於 4Gb 的文件。如果您想使用 Bruce Schneier 的分組密碼，請使用後續的 Twofish 算法，正如他所說。
此建議 4GB 使 $ \approx 2^{33} $ -bytes 因此，他們建議最多使用 $ 2^{30} $ 同一密鑰下的加密塊。如果你加密，生日機率 $ 2^{30} $ 你將擁有的塊
$$ (2^{30})^2/2^{64}/2 = 2^{60 - 64-1} = 1/2^{5} $$碰撞的機率。這在攻擊者的優勢中仍然是一個很大的機率。
什麼是 Sweet32 簡而言之：
對加密的 CBC 操作模式執行的攻擊$$ c_i = E_k(m_i \oplus c_{i-1}) $$與 $ c_{-1} $ 是 CBC 的隨機數。
一旦加密 $ 2^{n/2} $ 生日攻擊的一個密鑰塊 我們預計密文上的碰撞有 50% 的機率可以被竊聽者觀察到。這意味著 $ c_i = c_j $ 和 $ i \neq j $ 被觀察到。由於分組密碼是密鑰下的固定排列，這意味著 $ c_i $ 和 $ c_j $ 必須相同；
$$ m_i \oplus c_{i-1} = m_j \oplus c_{j-1} $$隨著改變我們得到的價值觀的一面$$ m_i \oplus m_j = c_{1-1} \oplus c_{j-1}. $$那就是竊聽者知道兩個消息塊的 x-or。
一個簡短的註釋填充預言；
Padding oracle 由 Serge Vaudenay 在 2002 年首次描述；
幾年後，真正的攻擊被執行。Vaudenay 將其應用於 CBC 模式下的 RC5，並且它適用於任何使用 CBC 模式的密碼，只要伺服器將填充失敗作為錯誤發送。使用填充預言機攻擊，所有消息都可以被洩露，因為它是一個解密預言機。Encrypt-than-Mac 將阻止這種攻擊。
更新評論；_
原來OP有X/Y問題；短字元串是密碼，那麼顯而易見的選擇是眾所周知的解決方案，例如密碼散列競賽 Argon2，獲勝者。它有兩種模式；
- Argon2d：速度更快，並且使用依賴於數據的記憶體訪問。數據依賴性立即啟用旁道。這適用於不受側通道攻擊威脅的加密貨幣和應用程序。
- Argon2i：使用與數據無關的記憶體訪問，這是密碼散列和基於密碼的密鑰派生的首選。
- 如果您不確定要使用哪一個，則可以使用組合模式Argon2id。