HQC deployment scenarios

[Demi Marie Obenour]

What are some circumstances under which deploying HQC makes sense?

Compared to ML-KEM, HQC has larger public keys and ciphertexts at
all NIST security levels. Furthermore, it is slower than ML-KEM on
application processors. I'm not sure about microcontrollers, FPGAs,
or ASICs.

While it could be used as a fallback if ML-KEM fails, or as a hybrid
with ML-KEM, this doesn't seem particularly compelling. Are there areas
where HQC is a better fit? For instance, is it more masking-friendly?
--
Sincerely,
Demi Marie Obenour (she/her/hers)

[John Mattsson]

Hi Mari,

- I think having a backup algorithm to ML-KEM based on a different mathematical problem is very important. I would like to see HQC-KEM standardized and implemented everywhere, even if it is rarely or never used. This is how the telecom industry has always approached cryptographic agility, diversity, and robustness.

- I'm don't think ML-KEM + HQC-KEM hybrids are super compelling, but I think they are considerably more compelling than ephemeral Classic McEliece or FrodoKEM. Similarly, I think PQ/PQ hybrids will soon (5–10 years) become much more compelling than PQ/T hybrids.

- I have heard claims that HQC may offer implementation advantages for IoT devices, but I have not yet seen convincing evidence to support those claims.

Cheers,

John Preuß Mattsson

--

You received this message because you are subscribed to the Google Groups "pqc-forum" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/33203c98-7212-4898-99fd-cdbc6f63f024%40gmail.com.

[Bas Westerbaan]

Similarly, I think PQ/PQ hybrids will soon (5–10 years) become much more compelling than PQ/T hybrids.

If in 5–10 years there hasn't been signfiicant progress against ML-KEM, then there seems to be little incentive to move to PQ/PQ hybrids. I expect folks will move from vestigial PQ/T hybrids directly to a new and more performant PQ KEM once it becomes available.

[Michael Scott]

And so it begins, the hybridisation combinatorial explosion.

We need NIST or some body to propose sensible standards for hybrids...

Mike

On Wed, Jul 29, 2026 at 9:43 AM 'Bas Westerbaan' via pqc-forum <pqc-...@list.nist.gov> wrote:

Similarly, I think PQ/PQ hybrids will soon (5–10 years) become much more compelling than PQ/T hybrids.

If in 5–10 years there hasn't been signfiicant progress against ML-KEM, then there seems to be little incentive to move to PQ/PQ hybrids. I expect folks will move from vestigial PQ/T hybrids directly to a new and more performant PQ KEM once it becomes available.

--

You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMjbhoVMuxOHutBRJPMBXjLiPUFdw%3DzTGwft8ozmdNQ%2B-pRqrQ%40mail.gmail.com.

[John Mattsson]

I did not say that I thought PQ/PQ hybrids should be widely deployed, I just said I think they will soon be much more compelling than PQ/T hybrids :) I think PQ/PQ hybrids make sense for high security use cases where performance does not matter.

Bas wrote:

>I expect folks will move from vestigial PQ/T hybrids directly to a new and more performant PQ KEM once it becomes available.

Maybe, but only if that new PQ KEM is equally trusted as ML-KEM. Otherwise, people likely want to wait a bit after standardization to use the new PQ KEM standalone.

Cheers,

John Preuß Mattsson

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAEseHRpLSHEfegtAHhrErnCROv16yaohJ9XD5jNL_SsFHiHm2Q%40mail.gmail.com.

[Bas Westerbaan]

Maybe, but only if that new PQ KEM is equally trusted as ML-KEM. Otherwise, people likely want to wait a bit after standardization to use the new PQ KEM standalone.

Certainly, similar as with RSA -> ECC.

Best,

 Bas

 

Cheers,

John Preuß Mattsson

From: 'Michael Scott' via pqc-forum <pqc-...@list.nist.gov>
Date: Wednesday, 29 July 2026 at 11:09
To: pqc-...@list.nist.gov <pqc-...@list.nist.gov>
Subject: Re: [pqc-forum] HQC deployment scenarios

And so it begins, the hybridisation combinatorial explosion.

We need NIST or some body to propose sensible standards for hybrids...

Mike

On Wed, Jul 29, 2026 at 9:43 AM 'Bas Westerbaan' via pqc-forum <pqc-...@list.nist.gov> wrote:

Similarly, I think PQ/PQ hybrids will soon (5–10 years) become much more compelling than PQ/T hybrids.

If in 5–10 years there hasn't been signfiicant progress against ML-KEM, then there seems to be little incentive to move to PQ/PQ hybrids. I expect folks will move from vestigial PQ/T hybrids directly to a new and more performant PQ KEM once it becomes available.

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMjbhoVMuxOHutBRJPMBXjLiPUFdw%3DzTGwft8ozmdNQ%2B-pRqrQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAEseHRpLSHEfegtAHhrErnCROv16yaohJ9XD5jNL_SsFHiHm2Q%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/AS4PR07MB882558C7F0F405955CD5F38389CA2%40AS4PR07MB8825.eurprd07.prod.outlook.com.

[Blumenthal, Uri - 0553 - MITLL]

It looks like in a few years hybrids will become obsolete — Bb the time the standards are reviewed and published, they already become useless.

--

V/R,

Uri

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                 C. A. R. Hoare

From: 'Michael Scott' via pqc-forum <pqc-...@list.nist.gov>

Date: Wednesday, July 29, 2026 at 05:09
To: pqc-...@list.nist.gov <pqc-...@list.nist.gov>
Subject: [EXT] Re: [pqc-forum] HQC deployment scenarios

This Message Is From an External Sender

This message came from outside the Laboratory.

 

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAEseHRpLSHEfegtAHhrErnCROv16yaohJ9XD5jNL_SsFHiHm2Q%40mail.gmail.com.

[Demi Marie Obenour]

Do you have any thoughts what that would be?

Lattice-based KEMs have a huge design space. Here are just some of the
tradeoffs I've seen:

- IND-1CCA vs IND-CCA2: If one only needs IND-1CCA, one can get
away with a much larger decryption failure rate. This allows
smaller modulus-to-noise ratios, increasing security without
needing new assumptions. IND-1CCA is provably sufficient in
some protocols, but misusing algorithms that are only IND-1CCA
allows key-recovery attacks exploiting decryption failures.

- Noise vs rounding: Using rounding without noise reduces ciphertext sizes,
at the cost of being a much less studied assumption.

- Rings vs modules vs unstructured lattices: If efficiency isn't super
important, unstructured lattices are very attractive. A simple
example of this use-case is layer 1 optical encryption of a 100Gb/s
link, where the cost of sending a 100KB message is only 8μs.
Otherwise, one can choose between rings and modules.

- NTT-friendly rings vs large Galois groups: the former allows faster
implementations at a (likely small) increase in attack surface.

- NTRU vs {R,M}LWE: the former allows for more efficient implementations
and tighter IND-CCA2 reductions, but while it is a well-studied
problem it might have more attack surface.

- Using error-correcting codes to reduce decryption failure allows even
smaller noise-to-modulus ratios, but makes it harder to determine
the decryption failure rate.

- For quotient NTRU, implicit rejection allows tighter IND-CCA2 proofs
than the T-transform does. For product NTRU and (ring, module,
or unstructured) LWE-based schemes, one must use the T-transform,
but this also means that explicit rejection is believed to be secure.

Code-based KEMs also have a large design space, if for no other
reason than that there are many different codes to choose from. Even
lattice-based hash-and-sign signatures have many possible trapdoors.

Given all of these choices, how likely is it that there is a
one-size-fits-all best algorithm? I know that explicit elliptic curve
parameters were a disaster, but also elliptic curves had a lot fewer
tradeoffs to make.

[Bo Lin]

Lightweight Authenticated Key Exchange

In the above post, the application scopes of ML-KEM and HQC were mentioned. Basically, if an application is suitable for ML-KEM, it would be expected to be suitable for HQC because both schemes have large key size and ciphertext size.

For HQC, a paper (Side-Channel Sensitivity Analysis on HQC: Towards a Fully Masked Implementation) gives a thorough side channel analysis.

For low-cost hardware implementation, HQC may be advantageous - textbook's RM en/de-coder's hardware is simple. In terms of RS en/de-coder's hardware, it is not very complicated and RS codes are widely used everywhere, such as hard-drives, CD, DVD, QR code, Low-cost IP should be readily available.

For devices, if there is no bandwidth limitation, HQC can be a viable option. They could be manufactured inexpensively and deployed in applications risking that devices could get lost.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/BN0P110MB1419A45E6541C8FC0B8843FF90CAA%40BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM.