>> 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).
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
