HQC-192 is the middle parameter set of the HQC code-based KEM family. It targets NIST Category 3 security, equivalent to AES-192 brute-force resistance, which is the middle of the three security categories NIST defined for post-quantum standardization. For organizations that want code-based KEM diversity at a stronger security level than HQC-128 but cannot afford the larger sizes of HQC-256, this is the parameter set that fits.
This post walks through HQC-192's parameters, performance, and the use cases where it makes sense.
Position in the HQC Family
NIST's HQC standard defines three parameter sets. HQC-128 at Category 1, HQC-192 at Category 3, and HQC-256 at Category 5. Like NIST's other PQC algorithms, the security category numbering corresponds to AES strength equivalents. Category 1 matches AES-128, Category 3 matches AES-192, and Category 5 matches AES-256.
The choice of parameter set typically reflects regulatory or organizational requirements. Many regulatory frameworks specify Category 3 as the minimum acceptable strength for non-classified sensitive data. HQC-192 fits that requirement directly.
Key and Ciphertext Sizes
For HQC-192, byte counts are.
Public key is 4,522 bytes. Secret key is 4,586 bytes. Ciphertext is 9,026 bytes. Shared secret is 64 bytes.
Compare to HQC-128, the Category 1 baseline. Public key 2,249 bytes, secret key 2,305 bytes, ciphertext 4,481 bytes. Moving from Category 1 to Category 3 roughly doubles all the byte counts.
Compare to ML-KEM-768, the lattice-based Category 3 alternative. Public key 1,184 bytes, ciphertext 1,088 bytes. ML-KEM-768 has dramatically smaller keys and ciphertexts than HQC-192. The size difference is the cost of using code-based cryptography instead of lattice cryptography.
Why Code-Based Diversity Matters
The case for HQC-192 specifically rests on the same principle as HQC-128. Mathematical foundation diversity protects against systemic risk.
If lattice cryptanalysis ever advances enough to threaten ML-KEM, every lattice-based scheme falls together. Hybrid encryption with both ML-KEM-768 and HQC-192 stays secure because the code-based component is unaffected.
The cost of this diversity is the larger sizes. A hybrid encryption that uses both ML-KEM-768 and HQC-192 produces ciphertexts totaling roughly 10 KB versus 1 KB for ML-KEM-768 alone. For files larger than a few hundred KB, this overhead is irrelevant. For tiny messages, it is more visible.
For deployments where Category 3 security is required and code-based diversity is desired, HQC-192 is the right component to pair with ML-KEM-768.
For more on hybrid encryption, see Hybrid Encryption.
Performance Characteristics
On modern x86 hardware, HQC-192 performs roughly as follows.
Key generation takes around one to two milliseconds. Encapsulation takes around one to two milliseconds. Decapsulation takes around one to two milliseconds.
Compared to ML-KEM-768 at the same security category, which performs all three operations in tens to low hundreds of microseconds, HQC-192 is roughly ten times slower. This performance gap reflects the more complex computations involved in code-based decoding compared to lattice polynomial arithmetic.
For most applications, HQC-192 is fast enough. Even at the slower end, decapsulation in under two milliseconds is fine for non-handshake workflows. For high-throughput TLS handshake servers, the gap matters more.
Quasi-Cyclic Code Structure at Category 3
HQC-192 uses quasi-cyclic codes with parameters tuned for Category 3 security. The polynomial degree is approximately twice that of HQC-128, and the noise parameters are scaled accordingly to maintain the security margin.
The decoding procedure used by the receiver to recover the encapsulated message remains conceptually similar across HQC parameter sets. What changes is the parameter values: degree, noise weight, and codeword length.
The mathematical assumption underlying HQC's security is that decoding random quasi-cyclic codes is hard. This problem has resisted classical and quantum cryptanalytic attacks for decades. The Category 3 parameters provide approximately 192 bits of brute-force resistance, with quantum adversaries reduced to approximately 96 bits via Grover's algorithm.
When HQC-192 Beats HQC-128
The decision between HQC-128 and HQC-192 typically comes down to regulatory requirements and bandwidth budgets.
HQC-192 wins when regulations or organizational policies mandate Category 3 minimum strength. Many government and high-assurance commercial deployments fall into this category.
HQC-128 wins when bandwidth is constrained and the regulatory framework allows Category 1. The 4.5 KB ciphertext difference per encryption is meaningful for some workflows.
For applications that practice maximum-conservatism encryption with both ML-KEM and HQC at high security category, HQC-192 paired with ML-KEM-768 is the natural Category 3 choice. The total ciphertext for hybrid encryption is roughly 10 KB.
When ML-KEM-768 Is Sufficient
Most deployments will use ML-KEM-768 alone for Category 3 KEM. ML-KEM-768 is faster, has smaller keys and ciphertexts, and is the primary NIST recommendation.
The case for adding HQC-192 alongside ML-KEM-768 is specifically about defense in depth. If the deployment cannot afford to depend on a single mathematical foundation, hybrid encryption with both schemes is the conservative choice.
For most commercial applications, ML-KEM-768 alone provides adequate post-quantum security. HQC-192 is the answer for the subset of applications that explicitly require code-based KEM diversity.
For more on KEM design, see ML-KEM Explained.
QNSQY Implementation
QNSQY's Business tier exposes HQC-192 alongside HQC-128 and HQC-256. The CLI accepts HQC-192 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-192, the resulting QNSQY envelope contains the HQC ciphertext (9,026 bytes plus envelope metadata) and an AES-256-GCM-encrypted payload. The total overhead from HQC-192 versus ML-KEM-768 is roughly 8 KB per encrypted file.
For deployments that use hybrid encryption with both ML-KEM-768 and HQC-192, the total per-file overhead is approximately 9 KB. For files larger than a few hundred KB, this is rounding error.
For more on QNSQY's approach to algorithm support, see HQC Explained.
Use Cases for HQC-192
The strongest case for HQC-192 is hybrid encryption at Category 3 for high-assurance applications.
Government cloud storage where data must be protected at Category 3 with defense in depth across mathematical foundations. The data may need to remain confidential for many years, and the hybrid approach hedges against unexpected cryptanalytic advances.
Healthcare records management where patient data must remain confidential under HIPAA-style regulations and the organization wants extra assurance beyond a single-foundation scheme. Category 3 is typical for this kind of data classification.
Long-term contractual document encryption where the document must remain confidential for the full life of the contract, possibly multi-decade. The hybrid scheme protects against future cryptanalytic surprises.
Financial transaction archives where regulatory retention periods extend many years and the data could become valuable to attackers over time. Category 3 with hybrid encryption hedges against the harvest-now-decrypt-later threat.
For more on the harvest-now-decrypt-later threat, see Harvest Now, Decrypt Later.
Constant-Time Implementation Concerns
Like other HQC parameter sets, HQC-192 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. Implementers building their own HQC must use constant-time pathways throughout. Side-channel testing should be part of any production HQC deployment validation.
QNSQY's HQC-192 implementation has been validated against side-channel test vectors and passes constant-time analysis on standard test platforms.
Failure Probability
HQC-192 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, 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-192 implementation must reproduce exactly.
QNSQY's HQC-192 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-192 implementation is interoperable with other compliant implementations.
For more on FIPS validation, see NIST FIPS Guide.
Hybrid Encryption Implementation
Hybrid encryption that combines ML-KEM-768 and HQC-192 requires careful design to ensure security composes properly. The standard pattern is independent encapsulation followed by KDF combination.
Step 1: The sender encapsulates with ML-KEM-768 using the receiver's ML-KEM public key. This produces an ML-KEM ciphertext and an ML-KEM shared secret.
Step 2: The sender encapsulates with HQC-192 using the receiver's HQC public key. This produces an HQC ciphertext and an HQC shared secret.
Step 3: The sender concatenates both ciphertexts and computes a KDF over both shared secrets to derive the final symmetric key. The KDF input typically includes both shared secrets, both ciphertexts, and any application-specific context.
Step 4: The sender uses the derived symmetric key with AES-256-GCM (or similar AEAD) to encrypt the actual data.
The receiver runs the equivalent operations in reverse. Decapsulate with both KEMs independently, derive the same symmetric key from the KDF, and decrypt the AEAD payload.
The security argument is that the hybrid scheme is secure as long as either ML-KEM-768 or HQC-192 remains secure. Both must fail simultaneously to compromise the encryption.
QNSQY's hybrid encryption follows this exact pattern. The KDF is HKDF with SHA-256, and the symmetric cipher is AES-256-GCM.
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).
The 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.
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.
A Realistic Sizing Example
Consider a healthcare records system that uses hybrid encryption (ML-KEM-768 plus HQC-192) for each patient record. Each record averages 50 KB of medical data.
Without hybrid encryption (ML-KEM-768 only), each encrypted record carries approximately 1 KB of KEM ciphertext overhead, for a total of 51 KB per record.
With hybrid encryption (ML-KEM-768 plus HQC-192), each encrypted record carries approximately 10 KB of KEM ciphertext overhead, for a total of 60 KB per record.
The 9 KB overhead per record is roughly 18 percent of the original record size. Across one million records, hybrid encryption adds 9 GB of storage versus single-foundation encryption.
Whether this is acceptable depends on the storage budget and the value placed on defense in depth. For high-assurance healthcare records, the storage overhead is generally acceptable in exchange for foundation diversity.
FAQ
Why is HQC-192 slower than ML-KEM-768?
HQC's decoding procedure involves more complex computations than ML-KEM's polynomial arithmetic. The performance gap is inherent to the different mathematical foundations.
Can I use HQC-192 alone without ML-KEM?
Yes. HQC-192 is a complete KEM and can be used standalone. NIST recommends using ML-KEM as the primary KEM and HQC as a backup or hybrid component, but standalone HQC deployment is allowed.
How does HQC-192 compare to BIKE in size?
BIKE is another code-based KEM that NIST evaluated but did not select. BIKE has similar size characteristics to HQC at comparable security levels. NIST selected HQC over BIKE for standardization.
Does HQC-192 require special hardware?
No. HQC-192 runs on any platform with integer arithmetic. There are no floating-point requirements or special hardware needs.
How long do HQC-192 encryption operations take on a phone?
On a modern smartphone CPU, HQC-192 operations take roughly 5-10 milliseconds each. This is fast enough for non-handshake workflows like file encryption. For real-time TLS handshake on a phone, ML-KEM-768 is faster.
Sources
- NIST PQC Project: HQC Selection Announcement
- HQC Round 4 Specification, NIST PQC Project
- NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
- NIST PQC KAT Test Vectors
- 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.