HQC-256 is the strongest parameter set of the HQC code-based KEM family. It targets NIST Category 5, equivalent to AES-256 brute-force resistance. For organizations that practice maximum-conservatism encryption with code-based KEM diversity at the highest security tier, HQC-256 is the algorithm. QNSQY makes it available exclusively in its Business tier alongside the rest of the NIST-standardized post-quantum suite.
This post walks through what HQC-256 looks like in practice, why some teams pick it specifically, and how QNSQY integrates it into hybrid encryption schemes.
Position in the HQC Family
The HQC family has three parameter sets. HQC-128 at Category 1, HQC-192 at Category 3, and HQC-256 at Category 5. The 256 in HQC-256 corresponds to the security category number, which targets AES-256 equivalence.
NIST selected HQC for standardization in March 2025 specifically as a code-based backup to ML-KEM. The reasoning was foundation diversity. If lattice cryptanalysis ever advanced enough to break ML-KEM, hybrid schemes that include HQC remain secure on their code-based component.
HQC-256 represents this code-based diversity at the highest security level NIST defined. For Category 5 hybrid encryption, HQC-256 paired with ML-KEM-1024 is the natural composition.
Key and Ciphertext Sizes
For HQC-256, byte counts are as follows.
Public key is 7,245 bytes. Secret key is 7,317 bytes. Ciphertext is 14,421 bytes. Shared secret is 64 bytes.
Compare to HQC-128 at Category 1. Public key 2,249 bytes, ciphertext 4,481 bytes. Moving from Category 1 to Category 5 roughly triples the public key and triples the ciphertext.
Compare to ML-KEM-1024, the lattice-based Category 5 alternative. Public key 1,568 bytes, ciphertext 1,568 bytes. ML-KEM-1024 is dramatically more compact than HQC-256.
The size difference is the cost of code-based cryptography at maximum security. HQC-256 ciphertexts at 14.4 KB are large enough to be visible in many protocols. For most workflows, this overhead is still acceptable.
Why Maximum Security Justifies the Size
The case for HQC-256 specifically rests on the combination of two requirements. Category 5 security and code-based foundation diversity.
Category 5 security gives margin against future cryptanalytic improvements over a long time horizon. Data that must remain confidential for thirty or forty years should be encrypted with Category 5 algorithms to provide buffer against incremental advances in attack capability.
Code-based foundation diversity gives margin against unexpected breakthroughs in lattice cryptanalysis. Most organizations expect lattice problems to remain hard, but a small probability of an unexpected advance exists. Code-based KEMs are unaffected by lattice advances. Hybrid schemes that combine both remain secure as long as one of the foundations holds.
For high-stakes data where both Category 5 security and foundation diversity matter, HQC-256 is the answer. The 14 KB ciphertext is the price.
Performance Characteristics
On modern x86 hardware, HQC-256 performs roughly as follows.
Key generation takes around two to four milliseconds. Encapsulation takes around two to four milliseconds. Decapsulation takes around two to four milliseconds.
Compared to ML-KEM-1024 at the same security category, which performs all three operations in tens to low hundreds of microseconds, HQC-256 is roughly ten to twenty times slower. This performance gap is consistent with the lattice-versus-code-based comparison at lower security categories.
For most applications, HQC-256 is fast enough. Even at the slower end, decapsulation in under five milliseconds is fine for non-handshake workflows. For high-throughput TLS handshake servers at Category 5, the gap is more significant.
Hybrid Encryption with ML-KEM-1024
The most common deployment pattern for HQC-256 is hybrid encryption with ML-KEM-1024. The receiver runs both KEMs independently. Each KEM produces a shared secret. The final shared secret used by the symmetric cipher is derived from both individual shared secrets via a KDF.
The mathematical security argument is that the hybrid scheme remains secure as long as either ML-KEM-1024 or HQC-256 remains secure. Both would have to fail simultaneously for the hybrid to be compromised.
The cost is approximately 16 KB additional ciphertext per encryption operation (HQC-256 ciphertext on top of ML-KEM-1024 ciphertext). For files larger than a few hundred KB, this is rounding error. For tiny messages, the overhead is more visible but usually acceptable.
This pattern matches NSA CNSA 2.0 guidance for the most security-sensitive deployments and matches NIST's transitional recommendations during the post-quantum migration.
For more on hybrid encryption, see Hybrid Encryption.
Use Cases Calling for HQC-256
A few scenarios genuinely call for HQC-256 specifically.
Government classified data archives where data must remain confidential for forty years or more. Category 5 plus code-based foundation diversity provides maximum protection against future cryptanalytic advances.
Long-term intellectual property vaults where the IP value extends decades beyond initial creation. Patent applications, trade secrets, and proprietary research archives all fit this profile.
National security communications archives where confidentiality requirements extend across multiple change of administration cycles. Hybrid encryption with HQC-256 provides assurance that the data remains confidential regardless of cryptanalytic developments.
Healthcare records archives subject to long retention requirements where patient privacy must be protected indefinitely. Category 5 with foundation diversity addresses both current and future threats.
Critical infrastructure encryption keys where the keys themselves must remain confidential for the life of the protected system. Encrypting the keys with HQC-256 ensures they cannot be recovered through future cryptanalytic advances against ML-KEM.
QNSQY Business Tier Offering
QNSQY exposes HQC-256 in its Business tier alongside the entire suite of NIST-standardized post-quantum cryptography. Free and Pro tiers offer ML-KEM only. The Business tier is the appropriate choice for users who want code-based KEM availability for hybrid encryption schemes or for defense in depth at the highest security level.
The QNSQY CLI accepts HQC-256 as a KEM algorithm choice on encryption operations. Internally, QNSQY uses the HQC reference implementation, which has been validated against NIST's published test vectors for HQC.
When a QNSQY user encrypts a file with HQC-256, the resulting QNSQY envelope contains the HQC ciphertext (14,421 bytes plus envelope metadata) and an AES-256-GCM-encrypted payload. The total overhead from HQC-256 versus ML-KEM-1024 is roughly 13 KB per encrypted file.
For deployments that use hybrid encryption with both ML-KEM-1024 and HQC-256, QNSQY produces a single combined envelope containing both KEM ciphertexts. The total per-file overhead is approximately 16 KB.
Constant-Time Implementation
Like other HQC parameter sets, HQC-256 requires constant-time decoding to avoid side-channel leaks. The decoding procedure can leak information about the secret key through timing or cache behavior if implemented naively.
The reference HQC implementation includes constant-time decoding routines that QNSQY uses. Side-channel testing has been part of QNSQY's validation process. The HQC-256 implementation passes constant-time analysis on standard test platforms.
For deployments where side-channel resistance is critical, additional hardware-specific testing is recommended. The reference implementation provides a strong baseline, but specific deployment hardware may have unique side-channel characteristics that warrant additional analysis.
Failure Probability
HQC-256 has a small but non-zero probability of decapsulation failure. The failure probability is bounded at roughly 2 to the negative 128, which is small enough to be ignorable in practice.
When a failure does occur, the receiver's internal consistency checks detect the failure and the protocol can request a retry. The receiver does not return error information that would allow the encapsulator to distinguish failure from success, which is important for IND-CCA security.
In practical deployment at internet scale, decapsulation failures are essentially never observed.
NIST KAT Validation
NIST published Known Answer Tests for HQC. These tests provide deterministic input-output pairs that any compliant HQC-256 implementation must reproduce exactly.
QNSQY's HQC-256 implementation passes all NIST KAT tests. This validation confirms the implementation behaves correctly for the specific test vectors. Production users can be confident that the HQC-256 implementation is interoperable with other compliant implementations.
For more on FIPS validation and KAT testing, see NIST FIPS Guide.
NIST Round 4 Selection History
HQC went through NIST's PQC standardization process from Round 1 through Round 4. The Round 4 selection in March 2025 picked HQC as the code-based KEM standard alongside ML-KEM (the lattice-based standard).
Four candidates entered Round 4: Classic McEliece, BIKE, HQC, and SIKE. SIKE was broken in August 2022 by an attack on the supersingular isogeny problem and removed from contention. The remaining three candidates underwent continued analysis.
NIST's selection criteria included security analysis depth, performance characteristics, key and ciphertext sizes, and implementation simplicity. HQC's quasi-cyclic code structure produces public keys that are dramatically smaller than Classic McEliece while maintaining security against known attacks. BIKE has similar size characteristics but received less analysis depth than HQC during the standardization process.
For organizations deploying code-based KEMs going forward, HQC is the standardized choice. NIST will publish formal FIPS standardization for HQC in the coming years following the standard standardization timeline.
Hybrid Encryption Implementation Details
Hybrid encryption that combines ML-KEM-1024 and HQC-256 follows the same pattern as other hybrid KEM combinations. The sender encapsulates with both KEMs independently, then derives a symmetric key from both shared secrets via a KDF.
The KDF input typically includes both shared secrets, both ciphertexts, and any application-specific context. This ensures that the derived key depends on both KEMs and that an attacker who somehow recovered one shared secret would still need to break the other to recover the symmetric key.
QNSQY's implementation uses HKDF with SHA-512 (since the shared secrets are 64 bytes each at this security level) and AES-256-GCM as the symmetric cipher. The total per-file overhead for hybrid Category 5 encryption is approximately 16 KB plus envelope metadata.
Storage Cost Analysis
Consider a government archive that encrypts ten thousand classified documents per year and must keep them confidential for forty years. Each document averages 100 KB.
With ML-KEM-1024 alone, each encrypted document carries approximately 1.6 KB of KEM ciphertext overhead. Forty years of archival adds approximately 640 MB of KEM ciphertext data total.
With hybrid encryption (ML-KEM-1024 plus HQC-256), each encrypted document carries approximately 16 KB of KEM ciphertext overhead. Forty years of archival adds approximately 6.4 GB of KEM ciphertext data total.
The 5.7 GB difference across forty years is roughly 1.4 percent of the total archive storage if the documents themselves total around 400 GB. For most archives, this overhead is acceptable in exchange for foundation diversity at maximum security.
For more on the value of long-term encryption guarantees, see Harvest Now, Decrypt Later.
Comparison to Classic McEliece at Category 5
Classic McEliece provides Category 5 security with public keys exceeding 1 MB and ciphertexts under 200 bytes. The trade-off is opposite to HQC-256.
For deployments where the public key can be distributed once and reused across many encryption operations, Classic McEliece's compact ciphertexts are appealing. For deployments where the public key changes frequently or where many parties must each have their own public key, the McEliece public key size becomes prohibitive.
HQC-256 strikes a different balance. Public key roughly 7 KB, ciphertext roughly 14 KB. Manageable in both directions.
NIST selected HQC over McEliece for standardization in part because of HQC's more practical public key sizes for general-purpose deployment.
FAQ
Is HQC-256 worth the size overhead?
For most applications, no. ML-KEM-1024 alone provides Category 5 post-quantum security at much smaller sizes. HQC-256 is for organizations that specifically need code-based foundation diversity.
How does HQC-256 compare to RSA-15360 in performance?
RSA-15360 (which targets Category 5 classical security) is dramatically slower than HQC-256 for both encryption and decryption. RSA-15360 is also impractical at typical deployment scale because of key generation time. HQC-256 is much more deployable.
Can HQC-256 be used standalone without ML-KEM?
Yes. HQC-256 is a complete KEM and can be used standalone. NIST recommends ML-KEM as the primary KEM, but standalone HQC deployment is allowed.
What are the secret key storage implications?
The 7,317-byte secret key is larger than ML-KEM-1024's 3,168-byte secret key. For deployments that store many keys, this is a meaningful storage cost. For deployments with few keys, the difference is invisible.
Does HQC-256 support batch operations?
Yes. Batch encapsulation and decapsulation are supported. The performance gain from batching is in the 10-30 percent range depending on batch size.
Sources
- NIST PQC Project: HQC Selection Announcement
- HQC Round 4 Specification, NIST PQC Project
- NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
- NSA CNSA 2.0 Suite Announcement
- IACR Cryptology ePrint Archive: HQC Analysis
Related Articles
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.