# Blowfish and Twofish: Schneier's Pre-AES Designs **Source**: https://quantumsequrity.com/blog/blowfish-twofish-history **Category**: Cryptography Foundations --- [← Back to Blog](../../blog.html) Cryptography Foundations # Blowfish and Twofish: Schneier's Pre-AES Designs 11 min read Before AES, the symmetric encryption world was a patchwork of designs from different teams, each with their own ideas about how to build a fast and secure block cipher. Two of those designs came from Bruce Schneier and his collaborators at Counterpane: Blowfish in 1993 and Twofish in 1998. Twofish was a finalist in the AES competition. Blowfish was a workhorse of 1990s and 2000s open-source software. Both are still around today, in narrow pockets, and both are good case studies in how cipher design has matured. Looking at where each one came from, where each succeeded, and where each is being phased out is a useful tour of the era that produced AES. ## The 1990s Cipher Landscape In 1993, when Schneier published Blowfish, the dominant block cipher was DES, with its known 56-bit key weakness. The cryptographic community knew DES was fragile and was actively building replacements. Some of those replacements came from large institutions, like IDEA from ETH Zurich. Some came from individuals frustrated with the slow pace of standards bodies, which is where Blowfish fits. Schneier wrote Blowfish partly because he wanted a free, unencumbered, fast cipher that anyone could use without paying patent royalties. DES was free but weak. IDEA was strong but patented. RC5 from Rivest was strong but also patented. Schneier offered Blowfish under no patent and put the spec in his book Applied Cryptography. The community picked it up almost immediately. By the mid-1990s, Blowfish was inside OpenSSH, OpenVPN, GnuPG, and a long list of password manager and disk encryption tools. It became the de facto symmetric cipher of the open-source world for a while. ## How Blowfish Works Blowfish is a Feistel cipher with 16 rounds. It uses a 64-bit block size, like DES, and supports keys from 32 to 448 bits. The key schedule is unusually expensive: it takes the key, applies a complex setup procedure that uses 4 KB of S-box data initialized from the digits of pi, and produces a set of round subkeys. The setup runs hundreds of cipher operations to derive the schedule. This expensive key schedule turned out to be both a feature and a problem. As a feature, it made brute-force key search slow, because each guess required a full key schedule. This is the same idea that bcrypt later applied to password hashing, which is no coincidence: bcrypt was built by Provos and Mazieres on the EksBlowfish key schedule. See [bcrypt Explained](bcrypt-explained.html) for that branch of the family tree. The problem is the 64-bit block size. Anything that ages well in cryptography eventually has to deal with the birthday bound, which says that a 64-bit block cipher leaks information after about 2 to the 32nd power blocks of data, or roughly 32 GB. The Sweet32 attack in 2016, covered in [Triple-DES Sunset](triple-des-sunset.html), demonstrated this in TLS for both 3DES and Blowfish. After Sweet32, any high-volume use of Blowfish was a liability. Blowfish never had a public attack on the cipher itself, in the sense of a key recovery faster than brute force. The Sweet32 problem is structural: it is about the block size, not the cipher. But that structural problem alone is enough to retire it from any new design. ## Twofish and the AES Competition When NIST opened the AES competition in 1997, looking for a replacement for DES, Schneier and his team submitted Twofish. The team included Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall, and Niels Ferguson. Twofish made it to the final round of five candidates, alongside MARS, RC6, Rijndael, and Serpent. Twofish was a deliberate response to the lessons of Blowfish. It used 128-bit blocks, fixing the Sweet32 style problem. It supported 128, 192, and 256-bit keys, matching the AES requirements. It used 16 Feistel rounds with key-dependent S-boxes derived from a fixed maximum distance separable matrix. The design emphasized flexibility: you could trade off setup speed against encryption speed, depending on how much memory you wanted to use. In the AES final-round analysis, Twofish was rated as conservative and well-analyzed but somewhat complex. The complexity made implementation slightly trickier, especially in hardware, where simpler designs were easier to verify. NIST eventually picked Rijndael, which became AES, partly because it was conceptually cleaner and easier to implement in both software and hardware. For the runner-up that came closest see [Serpent Cipher Explained](serpent-cipher-explained.html). Serpent was the most conservative of the AES finalists and is sometimes still preferred when paranoia outweighs speed. ## Why Rijndael Won and Twofish Did Not Twofish was not weaker than Rijndael in any measurable way. It is still a respected cipher, and after more than 25 years of public analysis, the best known attacks on Twofish do not approach practical key recovery. The reason it lost the AES competition is that NIST had to pick one cipher, and the criteria favored simplicity, ease of implementation, and hardware suitability. Rijndael's design philosophy is mathematically clean. It is built on a finite-field representation of the AES state, and the round function is straightforward to describe. Hardware implementations were efficient. Software implementations were fast. Side-channel resistance was easier to reason about, although timing-attack-resistant AES implementations took years to mature. Twofish was deeper but harder to teach. The key-dependent S-boxes and the maximum distance separable matrix mixing made the analysis richer but also made the cipher harder to implement correctly. In a competition where every implementation bug becomes a vulnerability for someone, NIST went with the simpler design. After AES was published as FIPS 197 in 2001, Twofish never gained widespread adoption. A few open-source projects, like TrueCrypt and its successors VeraCrypt and CipherShed, kept Twofish as an option. Some niche applications still use it, particularly where users want to chain different ciphers for layered defense. But mainstream protocols, TLS, IPsec, SSH, all moved to AES. ## Where Each One Lives Today Blowfish lives on in two places. The first is OpenBSD's bcrypt, which uses the EksBlowfish key schedule for password hashing. The bcrypt design is still actively recommended for password storage in 2026, although the Argon2id story is now stronger for new deployments. See [bcrypt Explained](bcrypt-explained.html) and [Argon2id Explained](argon2id-explained.html). The second is legacy software. Some VPN and disk encryption tools from the late 1990s still ship with Blowfish support. NIST never standardized Blowfish, so the formal disallowal track that hit 3DES does not directly apply, but the Sweet32 result effectively ended its viability for any new design. Twofish lives on as a niche cipher in tools that offer it as an alternative to AES for users who want diversity. VeraCrypt and similar tools support Twofish-and-AES chaining, where data is encrypted with both ciphers in series. The argument is that if either cipher fails, the other still protects the data. The counterargument is that this is not how modern threat models work, and the chained design adds complexity without changing the asymptotic security. For a hybrid approach that actually does pay for itself, see [Hybrid Encryption](hybrid-encryption.html). Modern hybrid designs combine classical and post-quantum primitives, not two classical ciphers, because the two failure modes are independent in a meaningful way. ## What These Designs Got Right Both Blowfish and Twofish got several things right that became standard practice for later ciphers. The first was open publication. Schneier put the spec in a book and released reference code. The cryptographic community could analyze the design, look for weaknesses, and publish findings. This open process became the norm. The AES competition formalized it. NIST runs every modern crypto standard, including ML-KEM and ML-DSA, through the same kind of open public review. The second was conservative round counts. Both ciphers used 16 rounds, more than the minimum needed for security against the attacks known at the time. The extra margin gave them headroom against future cryptanalysis. Modern primitives like ChaCha20 and AES use the same principle: pick a round count that is comfortably above the attack frontier, not one that hugs the line. The third was clean S-box design. Blowfish's S-boxes are derived from the digits of pi, a public source with no hidden structure. Twofish's are key-dependent and built from a vetted MDS matrix. Neither cipher relies on mysterious unexplained constants, which is important because hidden structure is exactly where backdoors hide. This lesson echoed forward into how AES was scrutinized and how every modern primitive is documented. ## What These Designs Did Not Foresee The single biggest thing both ciphers did not anticipate was the rise of post-quantum cryptanalysis. Nothing in the symmetric world is directly broken by Shor's algorithm. Grover's algorithm gives a quadratic speedup against brute-force key search, which means a 128-bit key has effective security around 64 bits in a quantum attacker's hands. The standard response is to double the key length, which is why 256-bit keys are recommended for any symmetric cipher used in long-lived data protection. Blowfish supports up to 448 bits and has no problem here. Twofish supports up to 256 bits and is fine. AES-256 is the modern default. The point is that post-quantum migration for symmetric primitives is straightforward: use longer keys. The hard part of the migration is asymmetric, key exchange and signatures. See [What Is Post-Quantum Cryptography](what-is-post-quantum-cryptography.html) for the full picture. The second thing neither cipher anticipated was the importance of authenticated encryption. Blowfish and Twofish are unauthenticated block ciphers. To use them safely you have to combine them with a message authentication code, like HMAC, in a careful way. The history of TLS is full of bugs caused by getting this combination wrong: padding oracle attacks, length extension attacks, encrypt-then-MAC versus MAC-then-encrypt debates. Modern designs use authenticated encryption modes like AES-GCM or ChaCha20-Poly1305 that bake the authentication into the cipher itself. See [AES-256-GCM Explained](aes-256-gcm-explained.html). ## How QNSQY Treats Legacy Ciphers QNSQY does not support Blowfish or Twofish. The symmetric primitives are AES-256-GCM and XChaCha20-Poly1305, both authenticated encryption with associated data. The block size is 128 bits for AES, well beyond any Sweet32 style risk. The key length is 256 bits, well beyond any Grover concern. The post-quantum primitives are ML-KEM and ML-DSA, in hybrid with X25519 and Ed25519. The hash function is BLAKE3. Password derivation uses Argon2id. None of the legacy 64-bit block ciphers are part of the design. The reason to leave Blowfish and Twofish out is not that they are broken in any direct sense. It is that the modern primitives have stronger security arguments, are faster on modern hardware, and have authenticated modes built in. Building a cipher suite around primitives from 1993 in 2026 would be like building a database around a file format from 1985: technically possible, professionally indefensible. ## Frequently Asked Questions **Is Blowfish still safe to use?** For low-volume encryption with a strong key, the cipher itself has no known practical attack. The 64-bit block size is the real problem. Sweet32 means that any high-volume use, like TLS or VPN, is vulnerable. New designs should use AES or ChaCha20 instead. Existing legacy data does not need to be re-encrypted urgently, but the migration plan should be in place. **Is Twofish still safe to use?** Yes, after 25 years of public analysis there is no practical attack. The 128-bit block size avoids the Blowfish Sweet32 problem. The reason it is rare today is that AES won the competition and absorbed the ecosystem, not that Twofish failed cryptographically. **Why is bcrypt still considered modern when it uses a Blowfish-derived schedule?** bcrypt uses the EksBlowfish key schedule for password hashing, where the cost factor is a feature, not a bug. The 64-bit block size does not matter in this context because bcrypt only outputs a 24-byte hash, far below the Sweet32 threshold. For new password storage, Argon2id is generally recommended over bcrypt, but bcrypt remains acceptable. **Did Twofish get broken during the AES competition?** No. Twofish made it to the final round and was considered secure. NIST selected Rijndael primarily because of simplicity and implementation efficiency, not because of any cryptographic weakness in Twofish. Twofish is still considered cryptographically sound today. **Should I use Twofish-and-AES chaining for extra security?** For most threat models, no. Chaining two classical ciphers does not add much real-world security against the threats that actually break crypto in practice, which are implementation flaws, side channels, and protocol mistakes. A well-designed system using AES-256-GCM is more secure than a chained system that the developer does not fully understand. The exception is where regulatory or audit requirements specifically call for cipher diversity. ## Sources 1. Schneier, B. "Description of a New Variable-Length Key, 64-Bit Block Cipher (Blowfish)." Fast Software Encryption 1993. https://www.schneier.com/academic/paperfiles/paper-blowfish-fse.pdf 2. Schneier, B. et al. "Twofish: A 128-Bit Block Cipher." NIST AES Submission 1998. https://www.schneier.com/wp-content/uploads/2016/02/paper-twofish-paper.pdf 3. NIST. "Report on the Development of the Advanced Encryption Standard (AES)." 2000. https://csrc.nist.gov/csrc/media/publications/conference-paper/2001/05/15/the-development-of-the-advanced-encryption-standard-/documents/r2report.pdf 4. NIST FIPS 197. "Advanced Encryption Standard (AES)." 2001. https://csrc.nist.gov/pubs/fips/197/final 5. Bhargavan, K. and Leurent, G. "On the Practical (In-)Security of 64-bit Block Ciphers." ACM CCS 2016 (Sweet32). https://sweet32.info/SWEET32_CCS16.pdf 6. Provos, N. and Mazieres, D. "A Future-Adaptable Password Scheme." USENIX 1999 (bcrypt). https://www.usenix.org/legacy/event/usenix99/provos/provos_html/ ## Related Articles - [AES-256-GCM Explained](aes-256-gcm-explained.html) - [Triple-DES Sunset](triple-des-sunset.html) - [bcrypt Explained](bcrypt-explained.html) - [Hybrid Encryption](hybrid-encryption.html) - [What Is Post-Quantum Cryptography](what-is-post-quantum-cryptography.html) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)