"Increased Attack Surface and Complexity:
- Every additional cryptographic primitive introduces new attack vectors.
Even well-understood algorithms like ECC can have implementation
vulnerabilities (timing attacks, side-channels, etc.);"
In case of an implementation error that would lead to a vulnerability, then an
attacker would need to find two implementation errors : one for ECC, one for
ML-KEM. Otherly said, and AFAIK, finding an implementation error would not
break the hybrid solution.
Besides, regarding implementation flaws, ML-KEM implementations have not yet
stood the test of time like ECC implementations have. And you really want to
rely on only on ML-KEM ? In particular in the frame of SNDL ?
Patrick
Le mercredi 1 juillet 2026 à 04:39:02 UTC+2, Blumenthal, Uri - 0553 - MITLL
<[email protected]> a écrit :
>> If the data must remain secure after CRQC - you do not get bonus points for
>> surviving only until CRQC. >>>> People explained eloquently enough already
>> why using SIKE as an argument is bad. >> I don't read all of the messages
>> on the list.
😃
> But it seems kind of curious not to do ECC no matter what you think.
Hmm… No matter what I think? ;-)
> What's the reasoning there? It's not costly, who cares.
In theory, adding another independent algorithm is beneficial, and at worst —
useless, but it doesn't in any case decrease the security of the combination.
In practice, however, it well may reduce the overall security, and here's why —
in no particular order.
But first — mandatory TL;DR
The core question is: Do we trust ML-KEM? If yes, adding ECC is an unnecessary
complexity. If no, we shouldn't be using it at all — hybrid or otherwise.
My reasoning in detail follows.
Increased Attack Surface and Complexity:
- Every additional cryptographic primitive introduces new attack vectors.
Even well-understood algorithms like ECC can have implementation
vulnerabilities (timing attacks, side-channels, etc.);
- We know how to do that, but DJB’s point was that there could be libraries
that didn’t get a clue;
- The integration logic between ML-KEM and ECC creates additional complexity
where subtle bugs can undermine the security of both components;
- Real-world implementations rarely achieve the theoretical independence
assumed in security proofs.
Certification and Compliance Burden:
- Hybrid implementations require certification of both the PQ and classical
components, plus their integration;
- This doubles the FIPS/compliance validation effort and timeline;
- Any updates to either component may trigger recertification of the entire
hybrid system.
Codebase Maintenance:
- Maintaining implementations of two separate cryptographic algorithms
increases technical debt (for no good reason);
- Testing complexity grows with hybrid configurations.
Combiner Function Risks:
- The method used to combine keys from both KEMs is itself a potential
vulnerability;
- Yes we know how to do that correctly, but didn’t DJB repeatedly commented
on the risks of some libraries not getting it (ML-KEM, for example) right?
Shouldn’t that logic apply to other components as well?
- Incorrect implementation of the combiner can actually weaken security
below what pure ML-KEM would provide.
Performance and Resource Overhead:
- Hybrid systems require additional computational resources, memory, and
bandwidth;
- In resource-constrained environments, this overhead may matter;
- Large multi-user servers may not appreciate this overhead because it
reduces the number of connections per unit of time, that in turn reduces their
revenue.
Infrastructure and PKI Complexity:
- Hybrid systems require maintaining parallel PKI infrastructures—both
classical and PQ certificate chains;
- This doubles the operational overhead: key generation, distribution,
rotation, revocation, and archival for both systems;
- Certificate sizes increase significantly, impacting storage and
transmission costs;
- Organizations must manage two separate sets of trust anchors, policies,
and operational procedures.
Implementation Footprint Concerns:
- ML-KEM alone has significantly larger key sizes and memory requirements
than ECC;
- Adding ECC on top further increases code size, RAM usage and storage
requirements;
- FPGA implementations may not be able to tolerate this;
- For constrained devices (IoT, embedded systems, smart cards), this
combined footprint may exceed available resources;
- Devices that could support pure ML-KEM might be unable to accommodate the
hybrid approach;
- This creates deployment barriers and may force continued use of
classical-only crypto in resource-limited environments.
- This already is a risk because of the orders-of-magnitude increase of the
pub keys and ciphertext sizes, no need to exacerbate it even more.
False Sense of Security:
- If ML-KEM is fundamentally broken, the ECC component only protects against
Classic attacks, not CRQC;
- This fails the main purpose of going to PQC;
- If the data needs long-term protection, and ML-KEM fails — you've already
lost (see above).
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
