{
  "decisive_reason": "the collision exists ONLY among attacker-owned keys (shared attacker-chosen z) on attacker-crafted INVALID ciphertexts, so (1) no honest key is ever in it (= the LEAK-BIND-K-PK property ML-KEM HAS), and (2) the CEK is random/sender-chosen/independently-wrapped, so a KEK collision among the attacker's own keys yields no decryption capability, no honest-victim misbinding, and one-way store-and-forward encryption has no session/transcript for an unknown-key-share to corrupt.",
  "flows": [
    {
      "attack": "Attacker enrolls two malicious keys (ek1->identity A, ek2->identity B) with shared z; builds one KEMRecipientInfo with a rejected kemct=c and encryptedKey=Wrap(KEK,CEK), KEK=KDF(J(z||c)); the same blob relabeled rid->B unwraps to the same CEK under dk2. 'One blob, two identities.'",
      "flow": "Malicious ML-KEM cert enrollment (CMS / S-MIME), single message",
      "rank": 2,
      "verdict": "FAILS",
      "why": "The CEK is random and attacker-chosen and the attacker owns BOTH dk1,dk2 -> a shared KEK confers zero new capability (it could already decrypt under both). CMS EnvelopedData makes NO injective-recipient or data-origin promise to violate (RFC 9629: content delivered 'from an unknown source'); recipient identity = private-key possession, and both identities are the attacker. AuthEnvelopedData binds content->CEK (attacker-chosen), not CEK->recipient-pk. SignedData signer is a separate layer the KEM key never touches."
    },
    {
      "attack": "Relying party fetches a recipient JWK from an attacker-influenced endpoint; attacker tries to make a JWE accepted as encrypted-to two keys, or force attacker-key and victim-key to the same CEK.",
      "flow": "Attacker-controlled JWK endpoint (JOSE / JWE, jku)",
      "rank": 3,
      "verdict": "FAILS",
      "why": "The jku premise is an ORTHOGONAL trust failure the attacker wins WITHOUT the KEM gap (serve your own key, read the message). The 'attacker-key and victim-key -> same CEK' outcome is cryptographically IMPOSSIBLE (needs the victim's honest secret z; forbidden by LEAK-BIND-K-PK). JWE CEK is random+wrapped, protected header is the AEAD AAD, and JOSE PQ-KEM omits sender authentication -> nothing to forge. Furthest of the three from an attack."
    },
    {
      "attack": "Attacker who controls one recipient key tries to impersonate another recipient or make the per-recipient key-wrap ambiguous.",
      "flow": "Multi-recipient CMS / group messaging",
      "rank": 1,
      "verdict": "FAILS",
      "why": "You cannot inject into an HONEST recipient's slot: their KEK=KDF(J(z_victim||c)) needs the secret z_victim (unknown). The only available collision is between two attacker-owned slots (= 'the attacker is present twice'); all recipients legitimately share the same CEK by design. The GENUINE published multi-recipient weakness (ePrint 2026/1374) is a weakest-path DOWNGRADE issue, ORTHOGONAL to the z-collision. Closest to 'having structure', but the structure is downgrade, not binding."
    }
  ],
  "honest_residue": "MAL-BIND-K-PK WOULD matter for a NON-STANDARD system that (i) accepts attacker-enrolled ML-KEM keys and (ii) treats the bare KEM shared secret / KEK-equality as a cryptographic PROOF that a ciphertext binds to one unique enrolled public key (e.g. a naive dedup, receipt, or key-confirmation layer bolted onto CMS). There the attacker's two enrolled keys could equivocate \u2014 but (1) none of the four deployed standards use the KEM that way, (2) it is a misuse of the primitive, and (3) even then the harm is limited to equivocation among the attacker's OWN identities. That is exactly what 'misuse-resistance' means: a real hygiene property, not a break of the flows as specified.",
  "kill_questions": [
    {
      "a": "No. The KEK only unwraps a sender-chosen random CEK; the attacker owns both keys and chose the CEK. No ability to predict, control, or learn any HONEST party's CEK.",
      "q": "The CEK is random and independently wrapped \u2014 does a KEK collision let the attacker do anything?"
    },
    {
      "a": "No. They can already decapsulate under both. The property is internal to keys they fully control; no honest counterparty, no secret they lacked.",
      "q": "Does the attacker gain anything from two keys -> one KEK when they already control both keys?"
    },
    {
      "a": "Essentially no. UKS is a property of INTERACTIVE, mutually-authenticated key agreement (a live session misattributing actions). Store-and-forward PKE has no session, no mutual auth, no online peer-belief; recipient identity IS private-key possession, and CMS/JOSE promise no injective binding.",
      "q": "Is unknown-key-share meaningful for one-way store-and-forward encryption?"
    },
    {
      "a": "No. CDM (2023/1933) + 'How to Hold KEMs' frame it as re-encapsulation/UKS relevant only where a protocol FAILS to bind the pk elsewhere; the deployed protocols they examine commit to everything. Schmieg (2024/523) requires attacker-generated malformed keys and names no deployed exploit. Uniform framing: misuse-resistance / defense-in-depth. No concrete break exists in the literature.",
      "q": "Does any published work give a concrete deployed break from a KEM MAL-BIND-K-PK failure?"
    }
  ],
  "module": "pqc_keytransport_exploitability",
  "primitive_anchor": "ML-KEM not MAL-BIND-K-PK but IS LEAK-BIND-K-PK (Schmieg 2024/523; CDM 2023/1933). Cited, not re-derived. This analysis is deployed-flow reasoning, not new crypto.",
  "question": "is the ML-KEM MAL-BIND-K-PK gap EXPLOITABLE in the deployed transcript-less key-transport flows, or robustness-only?",
  "related_but_different": "ePrint 2026/1374 'Analysing the Post-Quantum Security of S/MIME' finds a multi-recipient DOWNGRADE / mixed-mode weakness (weakest-path CEK recovery), NOT the binding gap \u2014 and does not surface the collision as exploitable.",
  "resolves": "upgrades the IT21 'exploitability unestablished' hedge to 'not exploitable in the three flows examined, with precise reasons' \u2014 a rigorous negative that strengthens the finding.",
  "sprint": 140,
  "status": "honest-closure analysis of THIRD-PARTY standards; still a robustness/hygiene observation, human+counsel; NEVER auto-promoted. No legal/novelty/FTO/essentiality/price conclusion.",
  "verdict": "ROBUSTNESS-ONLY in all three flows examined \u2014 no real exploit could be built"
}