{ "schema": "auturnal.deep-research-review.v2", "slug": "postquantum-protocol-composition", "title": "Replacing a Primitive Is Not Migrating a Protocol: Post-Quantum Key Establishment", "category": "Security & Cryptography", "dek": "A protocol-level examination of hybrid composition, authenticated negotiation, and the cost of larger key-establishment messages.", "abstract": "Post-quantum migration changes the behavior of a deployed protocol rather than merely replacing one cryptographic function. This analytical review uses official ML-KEM, KEM guidance, TLS, HKDF, HPKE, and hybrid-terminology documents to separate primitive correctness from authentication, transcript binding, negotiation, and operational policy. It examines why combining algorithm outputs requires a reviewed composition argument and why compatibility fallback can undermine an otherwise valid handshake. Two reproducible constructed figures account for raw key-establishment sizes and the probability of completing simplified packetized flights without retransmission. A standard-library companion reproduces an HKDF test vector and demonstrates ambiguity in unframed concatenation. These checks support arithmetic and encoding claims; they neither implement ML-KEM nor certify a hybrid protocol. Additional analysis addresses decapsulation behavior, resumption provenance, mixed deployments, and protocol termination boundaries. The proposed evaluation requires exact wire evidence, negative negotiation tests, and separate examination of confidentiality and authentication goals. The result is a scoped migration framework whose assumptions remain reviewable and whose failures can be observed. No new cryptanalytic result, quantum-computing forecast, or measured handshake performance is claimed.", "refs": [ "cs2-15-1", "cs2-15-2", "cs2-15-3", "cs2-15-4", "cs2-15-5", "cs2-15-6" ], "sections": [ [ "1. Migration changes a protocol contract", "Replacing a key-establishment primitive is only one part of a post-quantum migration. A deployed protocol also authenticates identities, encodes algorithm choices, binds messages to a transcript, handles malformed inputs, manages resumption, and transports larger objects through real networks. Its security claim belongs to that composition. This manuscript argues that a migration plan should be reviewed as a change in accepted protocol histories, not merely as a library upgrade.\n\nWe focus on key establishment using ML-KEM and on the boundary between traditional and post-quantum components. The analysis uses official NIST and IETF documents, keeping standardized primitive definitions separate from illustrative application constructions. Two deterministic models quantify raw key-establishment bytes and an intentionally simplified packet-loss sensitivity. Additional checks reproduce an HKDF test vector and demonstrate ambiguous concatenation. No quantum-computer arrival date, cryptanalytic security estimate, or measured handshake benchmark is invented. The intended contribution is a review framework that makes the assumptions behind hybrid composition, authentication, and fallback visible enough to challenge before a deployment labels its connections post-quantum.", [] ], [ "2. Six documents answer different questions", "FIPS 203 specifies ML-KEM and its parameter sets. NIST SP 800-227 provides broader guidance on KEM use, including the need for additional elements when authentication is required. RFC 8446 defines TLS 1.3's handshake and transcript processing. RFC 5869 specifies HKDF. RFC 9180 specifies HPKE as a composition of a KEM, key derivation, and authenticated encryption. RFC 9794 supplies terminology for post-quantum/traditional hybrid schemes.\n\nNone of these roles should be substituted for another. A primitive standard does not define a complete TLS migration, a key-derivation function does not prove an arbitrary combiner secure, and the word hybrid in HPKE does not by itself mean combining traditional and post-quantum public-key algorithms. Our source use is deliberately bounded to relevant definitions, size tables, and composition guidance. The FIPS landing page also carries an errata planning note, so an implementation must track the applicable corrections rather than assume a downloaded PDF is a timeless compliance checklist. This manuscript does not claim to implement every requirement in those standards or to certify any deployed cryptographic module.", [ "cs2-15-1", "cs2-15-2", "cs2-15-3", "cs2-15-4", "cs2-15-5", "cs2-15-6" ] ], [ "3. KEM correctness is not peer authentication", "A KEM has key generation, encapsulation, and decapsulation procedures. Encapsulation to a public key produces a ciphertext and shared secret; the holder of the corresponding secret key decapsulates. Correctness concerns agreement on that secret for valid executions, with whatever failure probability the scheme specifies. It does not establish which human, service, or domain owns the public key supplied to the sender.\n\nConsider an unauthenticated application that downloads a public key from an attacker-controlled response, encapsulates securely to it, and then encrypts a password using the resulting secret. The KEM can perform exactly as specified while the password reaches the attacker. This is a protocol counterexample to the claim that post-quantum key establishment alone authenticates a service. The repair requires an authenticated binding between the intended peer and its key, together with appropriate transcript integrity. SP 800-227 explicitly treats authentication as application-dependent and often requiring additional cryptographic elements. A migration inventory should therefore track confidentiality and authentication separately, including certificate chains, trust anchors, key distribution, and administrative provisioning.", [ "cs2-15-1", "cs2-15-2" ] ], [ "4. What a hybrid goal actually says", "A post-quantum/traditional hybrid scheme typically aims to retain a target property when one component remains secure, under a specified composition model. RFC 9794 distinguishes this from simply negotiating either a traditional or a post-quantum algorithm. Using one or the other is algorithm agility; combining their contributions is a different construction. The desired resilience is a theorem or design goal to establish, not a property obtained by placing two algorithm names in a configuration file.\n\nThe combiner must account for adversarially controlled or correlated inputs, component validity checks, key reuse, and the security property required by the outer protocol. A component that fails or produces a fixed output must not accidentally cause the implementation to skip the surviving contribution. Conversely, an application should not invent ad hoc recovery behavior that changes the agreed algorithm after a failure. Our example key-derivation expression illustrates explicit framing and context; it is not offered as a standardized hybrid KEM or an independently proved robust combiner. Deployment should use a reviewed protocol specification whose assumptions match its intended threat model and whose error behavior is fully defined.", [ "cs2-15-6" ] ], [ "5. Encoding is part of the cryptographic argument", "Suppose a program concatenates two variable-length secrets without framing. The byte strings ab followed by c and a followed by bc produce the same combined bytes. Even before considering the strength of a hash function, the encoding fails to distinguish two different component pairs. This constructed counterexample is checked directly by the companion program.\n\nLength prefixes or an unambiguous fixed-size grammar can remove this particular ambiguity, provided both peers enforce the same grammar. Domain labels and context then distinguish uses of the resulting material, such as handshake versus application traffic or client versus server roles. RFC 9180 discusses domain separation in its key-derivation design, while RFC 5869 separates extraction from expansion. These sources motivate careful composition but do not bless every framed concatenation. A review must follow the exact bytes into each cryptographic operation and verify that parser behavior agrees across implementations. Truncation, ignored trailing bytes, and multiple encodings of one logical field can reintroduce ambiguity outside the small example. Tests should therefore exercise the serialization boundary rather than testing only successful key agreement.", [ "cs2-15-4", "cs2-15-5" ] ], [ "6. Transcript binding and negotiation", "TLS 1.3 authenticates a transcript whose definition includes message types and lengths, with special handling for a HelloRetryRequest. The relevant lesson is that negotiation and retry behavior are cryptographic inputs rather than incidental transport metadata. A migration that adds an algorithm identifier or additional key share must preserve the exact binding specified by the protocol it implements.\n\nAn illustrative failure occurs when a client offers a hybrid mode, an intermediary suppresses that offer, and the client silently retries in a traditional-only mode without an authenticated policy decision. A successful traditional handshake may be fully valid while violating the client's requirement for hybrid protection. Preventing this requires a policy that distinguishes allowed compatibility fallback from an active downgrade and appropriate transcript coverage. Logging the final negotiated mode is necessary but insufficient if the application never checks it against the requirement. Tests should include unknown groups, malformed shares, retry messages, and inconsistent peer selections. Their expected outcomes should be rejection or a specifically authorized alternative, not a generic success that hides which protection was actually obtained.", [ "cs2-15-3" ] ], [ "7. Authentication migration is a separate track", "A connection can use post-quantum key establishment while authenticating its peer with a traditional signature chain. That arrangement may address one confidentiality objective while leaving a different authentication objective for future work. The two properties depend on different adversary timing and trust assumptions. It is therefore more precise to report the negotiated key-establishment mode and authentication mode separately than to apply a single unqualified secure label.\n\nFor stored encrypted traffic, an evaluator should identify which secrets an adversary would need to recover later and whether ephemeral secrets were erased. For active impersonation, the evaluator should identify which credentials and trust anchors must remain unforgeable at the time of the attack. This manuscript does not predict when a relevant quantum adversary will exist. It instead asks the organization to state the required confidentiality horizon and the operational lifetime of its authentication infrastructure. The inventory must include offline signing, firmware updates, service certificates, and internal credentials where they support the protocol under study. Updating the client-facing handshake leaves those dependencies unchanged unless the migration explicitly includes them.", [] ], [ "8. A reproducible size ledger", "FIPS 203 gives ML-KEM-768 an encapsulation key of 1184 bytes and ciphertext of 1088 bytes. In our constructed comparison, a traditional contribution occupies thirty-two bytes in each direction. Adding those contributions yields 1216 client-side key-establishment bytes and 1120 server-side bytes, for a total of 2336. The traditional-only comparison totals sixty-four bytes. These numbers exclude certificates, extensions, records, and transport headers.\n\nThe first figure also includes the other two standardized ML-KEM parameter sets using their official size table. It is a byte-accounting comparison, not an equal-security performance ranking: different parameter sets have different intended strength and implementation costs. The model explicitly labels the additional thirty-two-byte components as assumed contribution sizes, rather than claiming that these raw lengths describe a particular standardized TLS group. A useful migration report extends this ledger with actual encoded handshake messages and certificate chains captured from the chosen implementation. That evidence can expose whether a deployment's dominant size increase comes from key establishment, authentication, optional extensions, or repeated negotiation rather than from the primitive alone.", [ "cs2-15-1" ] ], [ "9. Packetization and the second figure", "The second constructed model adds 256 bytes of framing to each direction and divides each flight into chunks of at most 1200 bytes. The ML-KEM-768-plus-traditional example then occupies two chunks in each direction, four in total. The traditional-only example occupies one chunk in each direction, two in total. These are arithmetic chunks, not a claim about TLS records, TCP segments, QUIC datagrams, or a particular path MTU.\n\nAssume each chunk is independently lost with probability one percent and consider only completion without retransmission. The four-chunk success probability is 0.96059601, while the two-chunk probability is 0.9801. The second figure varies the assumed loss probability. This deliberately narrow model shows why a byte increase can interact with transport, but it does not predict measured handshake latency or connection failure. Real transports retransmit, congestion control changes timing, losses can be correlated, and packet coalescing may alter the count. A deployment study should measure those mechanisms directly while preserving this model as a transparent baseline whose assumptions can be rejected rather than silently inherited.", [] ], [ "10. Decapsulation failures and implementation behavior", "A KEM implementation must follow its specified input checks and failure behavior. Exposing internal distinctions through error text, response timing, or retry paths can create an interface that differs from the one analyzed cryptographically. FIPS 203 defines particular algorithm behavior; this manuscript does not replace it with a custom exception policy or infer that every malformed ciphertext should produce a publicly distinguishable error.\n\nThe system-level review should trace what happens from parser rejection through key scheduling to connection teardown. A library may return a value under an implicit-rejection design while the surrounding application performs an extra comparison that changes observable behavior. A service might log secret intermediate state while diagnosing an interoperability problem. These possibilities require concrete implementation inspection rather than a generic statement that the primitive is standardized. Tests should include malformed lengths, noncanonical encodings where applicable, corrupt ciphertexts, and resource-exhaustion limits. Any timing experiment must distinguish intended public parse failures from secret-dependent internal behavior, use controlled conditions, and avoid presenting a small negative result as proof of constant-time execution.", [ "cs2-15-1" ] ], [ "11. Resumption and long-lived state", "A migration does not end when a full handshake negotiates a new mode. Resumption mechanisms, session tickets, cached keys, and pre-shared credentials can create paths that no longer execute the same key-establishment operation. The security question is which earlier exchange established the resumed secret, what additional fresh contribution is required, and how long that state remains usable under the current policy.\n\nAn application that requires fresh hybrid establishment may need to reject or constrain tickets originating from an older mode. Another application may deliberately allow resumption under a documented policy. Either choice can be reasonable, but the provenance must be explicit and tested. Early data introduces additional replay and authentication considerations in the outer protocol and should not inherit a stronger claim merely because a future full handshake will complete. The evaluator should record policy changes across software restarts and rolling deployments, because mixed-version fleets may issue and consume tickets differently. These are protocol-state questions, and measuring only the preferred fresh-connection path leaves them unanswered.", [] ], [ "12. Inventory and rollout evidence", "An actionable inventory follows data across protocol termination points. A browser may negotiate one mode with a gateway while the gateway uses another mode to reach an internal service. The external connection's property does not automatically extend through the gateway. Backups, message queues, and application-level encryption may also have independent keys and confidentiality lifetimes. The migration scope should name those boundaries rather than claim that enabling one edge feature protects every copy of the data.\n\nA staged rollout can collect negotiated-mode coverage, handshake size, retry rates, and latency under representative networks. It should also preserve a clear separation between compatibility fallback and policy violations. A feature flag that silently permits traditional-only operation can improve a success dashboard while undermining the migration objective. The owner therefore needs an explicit acceptance criterion, such as which client populations require which modes and which failures are allowed to stop the connection. Rollback procedures should be reviewed against that criterion before rollout. Reversibility of an implementation change does not erase data exposed during a temporary weakening of the required cryptographic policy.", [] ], [ "13. Verification that supports the actual claims", "The companion program reproduces RFC 5869's first SHA-256 test vector, checks framed encoding against the concatenation counterexample, and verifies the packet-count and independent-loss arithmetic. This validates the small mechanisms used in the manuscript. It does not implement ML-KEM, TLS, HPKE, or a standardized hybrid exchange, and its HKDF helper is included for verification rather than offered as a production cryptographic library.\n\nA real migration evaluation should then test two independent implementations against the chosen protocol specification, including negative negotiation cases and resumed sessions. Capture exact wire lengths and compare them with the size ledger. Measure latency distributions under declared loss, bandwidth, and round-trip conditions, and identify whether retransmission or cryptographic work dominates each regime. Review key erasure and authentication-chain behavior separately. Fuzz parsers and require deterministic rejection of unsupported encodings within configured resource bounds. The falsifiable outcome is a set of claims tied to versions and protocol paths, not an aggregate performance score or a successful library self-test promoted to an end-to-end security certificate.", [] ], [ "14. A migration claim with a defined scope", "The defensible claim identifies which protocol version, key-establishment mode, authentication chain, resumption policy, and termination path were evaluated. It also states the remaining assumptions and the behavior when the required mode is unavailable. Standardized post-quantum primitives are essential inputs to that claim, but the composition and operational state determine what the deployed system actually provides.\n\nThe constructed results support modest conclusions. Raw key-establishment bytes can increase substantially, which may change packetization under an assumed framing model. Unframed concatenation can lose distinctions before cryptographic processing begins. A valid KEM exchange does not authenticate the intended peer. Each conclusion has a reproducible example and a clearly bounded implication. The next research tasks concern robust protocol-specific composition, transport-aware deployment evidence, and policy continuity across mixed fleets and resumed sessions. Treating those tasks as first-class parts of migration makes cryptographic agility useful while preventing compatibility machinery from silently redefining the security objective.", [] ] ], "section_kinds": [ "author_analysis_or_verification_proposal", "source_based_review", "author_analysis_or_verification_proposal", "source_based_review", "author_analysis_or_verification_proposal", "author_analysis_or_verification_proposal", "author_analysis_or_verification_proposal", "author_analysis_or_verification_proposal", "author_analysis_or_verification_proposal", "author_analysis_or_verification_proposal", "author_analysis_or_verification_proposal", "author_analysis_or_verification_proposal", "author_analysis_or_verification_proposal", "author_analysis_or_verification_proposal" ], "equations": [ { "tex": "\\Pr[\\operatorname{Decaps}(sk,c)=K]\\geq 1-\\varepsilon", "explanation": "Correctness for valid generated key pair and encapsulation (c,K); epsilon is scheme-defined, not estimated here." }, { "tex": "\\mathrm{TH}=H(M_1\\Vert\\cdots\\Vert M_n)", "explanation": "Schematic transcript hash; actual TLS includes message headers and special retry rules from RFC 8446." }, { "tex": "K=\\operatorname{HKDF}(\\operatorname{Encode}(z_T,z_Q),\\mathrm{context})", "explanation": "Illustrative framed composition only; not a standardized or proved robust combiner. Real HKDF uses explicit extract and expand inputs." }, { "tex": "B_{\\mathrm{keys}}=B_{pk}+B_{ct}+2B_T", "explanation": "Total raw contributions in the constructed two-direction example; B_T=32 bytes, excludes framing and certificates." }, { "tex": "n=\\left\\lceil\\frac{B_{pk}+B_T+H}{M}\\right\\rceil+\\left\\lceil\\frac{B_{ct}+B_T+H}{M}\\right\\rceil", "explanation": "Constructed chunk count: framing H=256 bytes per direction and maximum chunk M=1200 bytes; not transport-specific." }, { "tex": "P_{\\mathrm{no\\ loss}}=(1-p)^n", "explanation": "Independent chunk-loss probability p; excludes retransmissions and correlated loss." } ], "table": { "headers": [ "Constructed quantity", "Value", "Scope" ], "rows": [ [ "ML-KEM-768 pk and ciphertext", "1184 and 1088 bytes", "FIPS 203 Table 3" ], [ "Additional traditional bytes", "32 each direction", "Assumed" ], [ "Combined raw total", "2336 bytes", "Excludes other handshake data" ], [ "Four chunks, p=0.01", "0.96059601", "No-retransmission probability" ], [ "Two chunks, p=0.01", "0.9801", "No-retransmission probability" ] ] }, "protocol": [ "Inventory confidentiality horizons and authentication dependencies.", "Choose a reviewed protocol specification and pin implementation versions.", "Verify exact encoding, domain labels, and transcript coverage.", "Test malformed shares, unsupported modes, and retry transcripts.", "Reject fallback that violates the configured minimum policy.", "Record fresh and resumed-session mode provenance.", "Capture wire lengths including certificates and transport framing.", "Measure latency under declared loss and round-trip conditions.", "Test mixed-fleet deployments and gateway termination boundaries.", "Review secret erasure and failure behavior separately from interoperability." ], "limitations": [ "No ML-KEM or full handshake implementation is supplied.", "The illustrative HKDF combiner has no claimed composition proof.", "Raw size comparisons are not equal-security performance rankings.", "Packet loss is independent and retransmissions are excluded.", "The official FIPS errata spreadsheet was not independently audited.", "No quantum-adversary timeline or cryptanalytic estimate is claimed.", "Protocol-specific hybrid deployment standards require separate selection and review." ], "evidence": [ { "source": "cs2-15-1", "result": "FIPS 203 specifies ML-KEM and raw key/ciphertext sizes.", "boundary": "Primitive standard does not define a full migration; errata require tracking.", "locator": "Definitions; Table 3; landing-page planning note" }, { "source": "cs2-15-2", "result": "Authentication generally needs additional application-dependent elements.", "boundary": "KEM correctness alone does not bind identity.", "locator": "Authentication guidance, printed page 17" }, { "source": "cs2-15-3", "result": "TLS authenticates transcript messages with defined retry processing.", "boundary": "New constructions require their own exact binding.", "locator": "Sections 4.4 and 4.4.1" }, { "source": "cs2-15-4", "result": "HKDF separates extraction and expansion and supplies test vectors.", "boundary": "It does not prove arbitrary hybrid combinations.", "locator": "Section 2; Appendix A.1" }, { "source": "cs2-15-5", "result": "HPKE uses domain separation in its composition.", "boundary": "HPKE hybrid terminology does not imply PQ/T hybrid.", "locator": "Abstract; section 9.6" }, { "source": "cs2-15-6", "result": "PQ/T hybrid combines components rather than merely negotiating either.", "boundary": "Terminology is not a security proof.", "locator": "Sections 2 and 4" } ], "research_questions": [ "Which protocol-specific combiners retain their intended property under hostile component inputs?", "When do transport effects dominate the latency cost of larger handshakes?", "How can mode provenance survive resumption and mixed-fleet policy changes?" ], "kind": "ai_assisted_research_guide", "author": "Codex (AI)", "original_language": "en", "created_date": "2026-10-25", "published_date": null, "publication_status": "local_draft_pending_owner_upload", "version": 1, "previous_version": null, "analytic": "postquantum-protocol-composition", "peer_reviewed": false, "journal_publication": false, "disclosure": { "authorship": "Written by Codex (AI), with source-based technical synthesis and explicit author-constructed models.", "figures": "Reproducible analytical illustrations, not measured system benchmarks.", "review": "Codex team technical checks; no independent human or journal peer review." }, "review_scope": "Selected original records and explicitly identified sections were inspected; this is not an exhaustive systematic review or independent verification of source proofs.", "revision_note": "Initial local English manuscript." }