Mental model
In the previous lesson you saw three architectures (hybrid, pure, composite) and the regulatory disagreement behind them. This lesson focuses on “whichever architecture you choose, which costs and risks are you accepting”: complexity cost (more moving parts, more risk of wrong figures) and the downgrade attack surface (where it can break if the combiner is not designed correctly).
Complexity cost: a real example from the course’s own corpus
The best evidence that complexity is not an abstract idea happened in this course’s own raw research corpus (found in the Phase 1 audit): the overhead of a hybrid TLS handshake was stated with three different, contradictory figures in the same research file (2026-08-05.md): 2.2 KB in one place, 1.6 KB in another (repeated on 6 different lines), and a third difference implied by the file’s own table (~0.7 KB, but misreported in the prose as “1.1 KB”). None was corrected; all three sat side by side. More striking still: in the same file the claim that “the certificate chain grows by ~3.4 KB with hybrid” was carried into both the executive and the architect sections (the “at the table” text), but that figure is really the signature size difference of a single certificate (ML-DSA-65 3309B + Ed25519 64B), not the real chain-level difference; the file’s own table computes the real chain-level difference as +9.6 KB, nearly three times as much.
This real event is a concrete case, from this course’s own source material, of the claim “complexity = more risk of wrong figures”. In response, this course built its own figure by actually measuring: X25519 alone, ClientHello 308 BMEASURED; hybrid X25519+ML-KEM-768, ClientHello 1484 BMEASURED; real difference 1176 BDERIVED (measured with a real openssl s_client command, not estimated; you will measure it again in your own environment in M8). When presenting hybrid’s overhead to an architect, use this real measurement, not any of the three contradictory figures; and the measurement itself must be re-verifiable the next time dogrula runs.
Downgrade risk: where it is real, where it is exaggerated
The claim “hybrid/composite is open to downgrade attacks” is often heard, but it needs to be clear where the risk really lies. In TLS 1.3’s own design, extension negotiation (including which key exchange group is selected) is authenticated by the MAC in the Finished message; so an active attacker silently stripping the PQC extension and downgrading to classical-only without the parties noticing is something the protocol itself is designed to detect. The real risk is not in the protocol itself but in two places:
First, permitted fallback. If a system allows falling back to classical-only when the PQC group cannot be negotiated, for compatibility (a common configuration for compatibility with some older clients), an attacker can exploit that permission to force one of the parties to trigger the fallback. The fix, as ANSSI and BSI also recommend, is to make the PQC component mandatory (no fallback), not just “preferred”.
Second, combiner design. ANSSI’s own warning is clear: XORing two keys “provides security against passive attackers… but not against active attackers because of mix and match attacks.” So a weak combiner can cancel hybrid’s theoretical advantage (the security of two independent algorithms) in practice; the correct method, as ANSSI recommends, is to combine with a KDF (key derivation function) that includes context information, not plain concatenation or XOR.
The specific risk of parallel-stack/dual-cert: OR logic
In a system that chooses dual-cert/parallel-stack (completely separate, parallel certificate chains for classical and PQC) instead of composite (two signatures in one certificate), an extra design decision comes in: should a relying party consider both chains valid (AND logic, real hybrid security), or is either one enough (OR logic)? Verification designed with OR logic means an attacker who breaks the classical algorithm (in the future, with a large enough quantum computer) can bypass the PQC chain with no effort; that completely reverses hybrid’s promise of being “as secure as the strongest component, not the weakest”. Composite (one object, one verification logic) has the advantage of avoiding this specific risk, but as you saw in the previous lesson, composite’s own standard (composite ML-DSA) has not yet become an RFC. When presenting these two approaches to an architect, the most concrete, actionable advice of this module is: if dual-cert is chosen, the verification logic must be explicitly documented and tested as AND.