# Camellia: The NTT/Mitsubishi AES Alternative **Source**: https://quantumsequrity.com/blog/camellia-cipher-explained **Category**: Cryptography Foundations --- [← Back to Blog](../../blog.html) Cryptography Foundations # Camellia: The NTT/Mitsubishi AES Alternative 11 min read In the late 1990s, while NIST was running the AES competition in the United States, a parallel effort was happening in Japan. Nippon Telegraph and Telephone, NTT, and Mitsubishi Electric jointly developed Camellia, a 128-bit block cipher with the same security goals as AES. Camellia did not enter the NIST competition because it was published after the deadline, but it became Japan's national reference cipher and was eventually standardized by ISO/IEC, IETF, and the European NESSIE project. It is one of the few ciphers in the world that has been adopted as a standard by multiple international bodies and remains, three decades after its design, an option in TLS and IPsec. The story of Camellia is a useful look at how cryptographic ecosystems evolve outside the US-dominated standards bodies, and how a strong but lesser-used cipher can still hold its place. ## Why Camellia Exists When NIST announced the AES competition in 1997, the rules required submissions by mid-1998 and only allowed entrants who could meet the licensing terms NIST set. Several strong cipher designs from outside the US were not formally entered, either because they missed the deadline or because their developers did not want to commit to the AES royalty terms. NTT and Mitsubishi were both major Japanese telecommunications and electronics firms with internal cryptography research groups. They had been working on block cipher designs through the 1990s, and in 2000 they jointly published Camellia. The name comes from the camellia flower, which is associated with Japan and with the corporate identity of NTT. The two firms had practical reasons to want a non-US cipher. Japanese government and corporate systems were increasingly tied to international standards, but there was institutional preference for a domestically developed primitive that the country could vouch for. Camellia gave them that. The design team included researchers from both NTT and Mitsubishi, with Kazumaro Aoki, Tetsuya Ichikawa, Masayuki Kanda, Mitsuru Matsui, Shiho Moriai, Junko Nakajima, and Toshio Tokita as the public authors. Matsui in particular was already well known in the cryptanalysis community as the inventor of linear cryptanalysis, the technique that broke the original DES. ## How Camellia Works Camellia is a Feistel-network cipher, similar in shape to DES and Blowfish, but with modern parameter choices. It uses 128-bit blocks and supports keys of 128, 192, or 256 bits. The 128-bit version uses 18 rounds. The 192-bit and 256-bit versions use 24 rounds. Each round applies a function called F to half of the state, XORs the result with the other half, and swaps. The F function uses a substitution-permutation structure with four 8-bit S-boxes derived from algebraic operations in finite fields. Every six rounds, Camellia inserts an additional layer called FL/FL-inverse, which mixes the state in a different way and disrupts certain classes of attack. The design is conservative. The S-boxes are based on the same kind of algebraic constructions that AES uses, although the specific mappings differ. The round count is generous, leaving comfortable headroom against the cryptanalytic attacks known at the time. After more than 25 years of public analysis, no practical attack on Camellia has been published. For comparison with the Feistel ancestors see [Blowfish and Twofish: Schneier's Pre-AES Designs](blowfish-twofish-history.html). For the substitution-permutation alternative that won the AES competition see [AES-256-GCM Explained](aes-256-gcm-explained.html). ## Standardization Path Camellia was published in 2000 and almost immediately moved into the international standardization process. The early milestones were: In 2002, the European NESSIE project, the New European Schemes for Signatures, Integrity, and Encryption, selected Camellia as one of its recommended block ciphers. NESSIE was the European answer to AES, run from 2000 to 2003, and its endorsement gave Camellia a non-Japanese seal of approval. In 2003, Japan's CRYPTREC committee, the Cryptography Research and Evaluation Committees of the Japanese government, listed Camellia in its e-Government Recommended Ciphers List. CRYPTREC is the body that vets cryptographic primitives for use in Japanese government systems. In 2005, ISO and IEC published ISO/IEC 18033-3, "Information technology, Security techniques, Encryption algorithms, Part 3: Block ciphers." Camellia was listed as one of the standardized 128-bit block ciphers, alongside AES and others. The IETF added Camellia to TLS through RFC 5932, published in 2010, and to IPsec through several other RFCs. Browser and server software added support, although adoption stayed low compared to AES. ## Where Camellia Is Used In production today, Camellia is most common in three contexts. The first is Japanese government and large enterprise deployments, where domestic preference and CRYPTREC compliance keep it in the rotation. Some Japanese ATMs, banking systems, and government communications use Camellia in addition to or instead of AES. The second is TLS configurations that explicitly enable Camellia cipher suites. The OpenSSL library has supported Camellia for years, and configurations that want cipher diversity can include Camellia alongside AES. In practice this is rare in public-facing web traffic but can show up in internal enterprise networks. The third is libraries that aim for international compatibility. Tools like GnuPG and some VPN products include Camellia as a selectable cipher. Most users never select it, but the option is there. Camellia adoption never reached the scale of AES because AES had three structural advantages: it was the US federal standard, hardware vendors implemented it in CPU instructions, and the ecosystem of TLS and IPsec implementations defaulted to it. Camellia matched AES on security and standardization but lost on momentum. ## Camellia Versus AES on Cryptographic Merits A fair head-to-head comparison shows the two ciphers are extremely close in security posture. Both have 128-bit blocks, support 128/192/256-bit keys, and use round counts that leave comfortable margin against known attacks. Both have been analyzed extensively by the public cryptographic community. Neither has a practical attack. AES has a slight edge in two narrow areas. First, hardware support: AES-NI instructions on x86 and equivalent instructions on ARM make AES dramatically faster than software-only ciphers. Camellia has no equivalent CPU acceleration on most platforms, so software Camellia is several times slower than hardware AES. Second, side-channel research: AES has had more public attention to timing attacks, cache attacks, and constant-time implementation, simply because more people use it. Camellia implementations may have lurking side-channel issues that have not been studied as thoroughly. Camellia has a slight edge in one area: design conservatism. The Feistel structure with FL/FL-inverse layers is harder to attack with certain algebraic techniques that have been applied to AES, although the AES attacks have not produced practical breaks either. For users who want a backup cipher in case some unforeseen weakness emerges in AES, Camellia is the most credible non-AES choice. For more on cipher diversity strategies see [Hybrid Encryption](hybrid-encryption.html), although the modern hybrid story is about classical-plus-post-quantum, not classical-plus-classical. ## CRYPTREC and the Japanese Crypto Ecosystem CRYPTREC deserves a brief tour because it is one of the few non-US national crypto evaluation bodies that the international community pays attention to. CRYPTREC was established in 2000 by Japan's Ministry of Internal Affairs and Communications and the Ministry of Economy, Trade, and Industry. It produces an annual list of Japanese-government-recommended cryptographic algorithms. The CRYPTREC list includes Camellia for 128-bit block ciphers, AES as well, and several non-Japanese designs. For hash functions, CRYPTREC lists SHA-256 family members and reviewed BLAKE2 in past evaluations. For asymmetric primitives, CRYPTREC has tracked the NIST post-quantum competition closely and is moving toward ML-KEM and ML-DSA recommendations. The CRYPTREC process is similar to NIST's, but with a stronger preference for Japanese-developed primitives where they exist. Camellia is the most internationally visible CRYPTREC choice. Most others, including some hash functions and KEM candidates, never gained traction outside Japan. For the global standards picture see [NIST FIPS Guide](nist-fips-guide.html). ## Camellia and Post-Quantum Cryptography Symmetric ciphers like Camellia are not directly broken by quantum computers. Grover's algorithm offers a quadratic speedup against brute-force key search, which means a 128-bit key has effective quantum security around 64 bits. The standard response is to use 256-bit keys for any data that needs to stay confidential past Q-day. Camellia-256 is fine for this. AES-256 is also fine. The hard part of post-quantum migration is asymmetric: key exchange and signatures. Camellia plays no role there. The replacements come from the NIST post-quantum standardization process, which produced ML-KEM and ML-DSA. See [What Is Post-Quantum Cryptography](what-is-post-quantum-cryptography.html) and [ML-KEM Explained](ml-kem-explained.html). A modern hybrid TLS deployment might combine ML-KEM-768 with X25519 for key exchange, ML-DSA-65 with Ed25519 for signatures, and AES-256-GCM or Camellia-256-GCM for symmetric encryption. The cipher choice for the symmetric part is mostly a matter of preference and hardware availability. ## Camellia in the Long Run Camellia's long-term position is as a respected secondary cipher rather than a primary one. It will continue to appear in TLS cipher suite lists, in OpenSSL configurations, in Japanese government deployments. It will not displace AES in any major ecosystem. The lesson from Camellia is that cryptographic standards are partly technical and partly political. A cipher with equal or better cryptographic properties can still lose adoption if the ecosystem favors the alternative. AES had the US federal standardization, the hardware acceleration, and the network effect. Camellia had the international standardization but not the network effect. For users designing new systems, the safest choice is AES-256-GCM with hardware acceleration. The second-safest choice is ChaCha20-Poly1305 if you are running on hardware without AES instructions. Camellia is a reasonable third choice if you have specific reasons to want it, like Japanese regulatory compliance or cipher diversity in a defense-in-depth design. ## How QNSQY Approaches Symmetric Cipher Selection QNSQY uses AES-256-GCM and XChaCha20-Poly1305 as its symmetric primitives. The reasoning is straightforward. AES-256-GCM gets hardware acceleration on every modern CPU, so encryption and decryption are nearly free in performance terms. XChaCha20-Poly1305 is the fallback for devices without AES hardware and for use cases where the extended nonce length is helpful. Camellia is not in the QNSQY cipher list. The reason is not that Camellia is weak. It is that the QNSQY threat model does not benefit from cipher diversity in the symmetric layer, and adding more cipher options creates implementation surface that has to be audited and maintained. The hybrid posture in QNSQY is at the asymmetric layer: ML-KEM with X25519, ML-DSA with Ed25519. That is where diversity matters, because that is where quantum computing changes the threat landscape. For the broader QNSQY architecture, see [Hybrid Encryption](hybrid-encryption.html), [AES-256-GCM Explained](aes-256-gcm-explained.html), and [X25519 and Ed25519 Explained](x25519-ed25519-explained.html). ## Frequently Asked Questions **Is Camellia as secure as AES?** On cryptographic merits, yes. Both are 128-bit block ciphers with 128/192/256-bit keys, both have been extensively analyzed, and neither has a practical break. AES has more public side-channel analysis because it is more widely deployed, which is a real but incremental difference. **Why does anyone use Camellia instead of AES?** Three main reasons: Japanese regulatory or institutional preference, cipher diversity in defense-in-depth designs, and historical inertia in systems that adopted Camellia before AES became universal. For most new deployments, AES is the default and Camellia is a curiosity. **Is Camellia in the NIST FIPS list?** No. Camellia is standardized by ISO/IEC and IETF and is on the CRYPTREC recommended list, but NIST FIPS standards focus on AES for symmetric encryption. Camellia is not approved for US federal government use under FIPS. **Can Camellia be hardware accelerated?** Some chips, particularly in Japanese-developed hardware, support Camellia in dedicated instructions. Mainstream x86 and ARM CPUs do not. As a result, software Camellia runs at a fraction of the speed of hardware-accelerated AES on the same machine. **Will Camellia survive the post-quantum transition?** Yes. Camellia is a symmetric cipher, and Grover's algorithm only halves the effective key strength. Camellia-256 has effective post-quantum security around 128 bits, which is enough. The post-quantum migration is about asymmetric primitives, not symmetric ones. ## Sources 1. Aoki, K. et al. "Specification of Camellia, A 128-bit Block Cipher." NTT/Mitsubishi 2000. https://info.isl.ntt.co.jp/crypt/eng/camellia/dl/01espec.pdf 2. ISO/IEC 18033-3:2010. "Information technology, Security techniques, Encryption algorithms, Part 3: Block ciphers." https://www.iso.org/standard/54531.html 3. IETF RFC 5932. "Camellia Cipher Suites for TLS." 2010. https://datatracker.ietf.org/doc/html/rfc5932 4. NESSIE Consortium. "NESSIE Security Report." 2003. https://www.cosic.esat.kuleuven.be/nessie/deliverables/D20-v2.pdf 5. CRYPTREC. "e-Government Recommended Ciphers List." Annual updates. https://www.cryptrec.go.jp/en/list.html 6. NIST FIPS 197. "Advanced Encryption Standard (AES)." 2001. https://csrc.nist.gov/pubs/fips/197/final ## Related Articles - [AES-256-GCM Explained](aes-256-gcm-explained.html) - [Blowfish and Twofish: Schneier's Pre-AES Designs](blowfish-twofish-history.html) - [Hybrid Encryption](hybrid-encryption.html) - [NIST FIPS Guide](nist-fips-guide.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)