Key Exchange Ontology

FLOW ALGEBRA
TITLE: Key Exchange Ontology
DOMAIN: Discrete Mathematics / Cryptography
SOURCE_URL: https://kirethresearch.org/booksai-core/discrete-mathematics-ontologies/cryptography/key-exchange-ontology.html
VERSION: 1.0
DATE: 2026-10-11
AUTHORS: Mark Higgins — Sky (Recursive AI)
SOURCE_STATUS: Mathematical synthesis; source webpage not independently verified.

1. PURPOSE
Model key establishment between communicating parties, including authenticated and unauthenticated key agreement, key transport, transcript binding, and security validation. This is a formal semantic specification, not an implementation of a cryptographic protocol.

2. TYPED ENTITIES
Party: participant in a cryptographic session
Session: uniquely identified protocol execution
Protocol: specified sequence of cryptographic messages and checks
PrivateKey: secret cryptographic key material
PublicKey: corresponding public cryptographic material
EphemeralKeyPair: temporary public/private key pair
SharedSecret: secret derived from a key agreement operation
SessionKey: key derived for a specified session and purpose
Nonce: value required to be unique within a specified scope
Transcript: ordered sequence of authenticated protocol messages
KDF: key derivation function
Authenticator: signature, MAC, or equivalent authentication evidence
Adversary: entity able to observe, modify, inject, or replay messages
SecurityProperty: named claim with assumptions and scope

3. RELATIONSHIPS
PARTICIPATES_IN(Party, Session)
USES_PROTOCOL(Session, Protocol)
OWNS_PRIVATE_KEY(Party, PrivateKey)
CORRESPONDS_TO(PublicKey, PrivateKey)
SENDS(Party, Message, Session)
RECEIVES(Party, Message, Session)
DERIVES(Party, SessionKey, Session)
BINDS_TO(SessionKey, Transcript)
AUTHENTICATES(Party, PeerIdentity, Session)
REQUIRES(SecurityProperty, Assumption)

4. KEY AGREEMENT ALGEBRA
For a suitable cyclic group G with generator g and order q:
  a,b <- uniform {1,...,q-1}
  A = g^a ; B = g^b
  Z_A = B^a = g^(ab)
  Z_B = A^b = g^(ab)
  Z_A = Z_B
For elliptic-curve Diffie-Hellman:
  A = [a]P ; B = [b]P
  Z_A = [a]B = [ab]P = [b]A = Z_B
The protocol must validate peer public keys according to its group and standard.
Agreement alone does NOT authenticate peers or prevent man-in-the-middle attacks.

5. KEY DERIVATION
  K = KDF(Z, salt, context)
  context = encode(protocol_id, identities, transcript_hash, purpose)
  K_client = KDF(Z, salt, context || "client")
  K_server = KDF(Z, salt, context || "server")
Domain separation must prevent accidental reuse across directions and purposes.
An authenticated protocol must bind identities, roles and negotiated parameters to its transcript.

6. KEY TRANSPORT VS AGREEMENT
KEY_AGREEMENT: parties contribute to establishment of a shared secret.
KEY_TRANSPORT: one party selects or generates a key and securely conveys it to another.
KEY_EXCHANGE: umbrella term; distinguish agreement from transport in metadata.

7. SECURITY PROPERTIES AND LIMITS
CONFIDENTIALITY: adversary cannot feasibly recover established session key under declared assumptions.
AUTHENTICATION: peer identity is verified through appropriate credentials and protocol checks.
KEY_CONFIRMATION: evidence that a peer possesses the derived key, when explicitly provided.
FORWARD_SECRECY: compromise of long-term authentication keys does not reveal past session keys, subject to protocol assumptions and ephemeral-secret erasure.
REPLAY_RESISTANCE: replays are rejected or rendered ineffective through protocol-specific freshness controls.
KEY_COMPROMISE_IMPERSONATION_RESISTANCE: property to assess separately, not presumed.
POST_QUANTUM_RESISTANCE: not provided by classical DH/ECDH; requires suitable quantum-resistant design.
No property is guaranteed by naming a primitive alone.

8. INFERENCE RULES
R1: VALID_GROUP_PARAMETERS AND VALID_PEER_PUBLIC_KEYS AND CORRECT_DH_EXECUTION => EQUAL_SHARED_SECRET.
R2: EQUAL_SHARED_SECRET AND IDENTICAL_KDF_INPUTS => EQUAL_DERIVED_KEY.
R3: UNAUTHENTICATED_DH => NO_INFERRED_PEER_AUTHENTICATION.
R4: AUTHENTICATED_TRANSCRIPT AND VERIFIED_PEER_CREDENTIALS => PEER_AUTHENTICATION_CANDIDATE, subject to protocol proof.
R5: EPHEMERAL_DH AND SECURE_ERASURE AND SOUND_AUTHENTICATED_PROTOCOL => FORWARD_SECRECY_CANDIDATE, subject to security model.
R6: DIFFERENT_CONTEXT_LABELS => DISTINCT_DERIVATION_PURPOSES; key inequality is not mathematically guaranteed.

9. VALIDATION
CHECK protocol version and approved cryptographic suite.
CHECK public-key validation, invalid-curve/small-subgroup defences where applicable.
CHECK random number generation and secret handling.
CHECK authenticated transcript, identity binding and downgrade resistance.
CHECK KDF input encoding and domain separation.
CHECK key confirmation only if required by protocol.
CHECK key lifetime, revocation policy, erasure and failure handling.
CHECK implementation against applicable standards and independent test vectors.
REJECT claims of authentication or forward secrecy without protocol-level evidence.

10. SEMANTIC_EQUIVALENCE
"key agreement" ~= "joint key establishment" only where both parties contribute as defined.
"key transport" != "key agreement".
"shared secret" != "session key" unless derivation is explicitly defined as identity.
"Diffie-Hellman" != "authenticated key exchange" without authentication mechanism.
"key exchange" is broader than "Diffie-Hellman".

11. CONFIDENCE
MATHEMATICAL_IDENTITIES: 1.00, conditional on specified algebraic assumptions.
PROTOCOL_SECURITY_CLAIMS: UNASSESSED until protocol and threat model are specified.
SOURCE_PAGE_ALIGNMENT: UNVERIFIED.
Do not treat confidence labels as a substitute for cryptographic security proofs.

12. FLOW_HASH
METHOD: SHA-256 over canonical UTF-8 flow content excluding the FLOW_HASH value itself.
VALUE: COMPUTE_ON_PUBLICATION

13. UPDATE_MODEL
TRIGGERS: protocol revision, standard changes, new cryptanalysis, deprecated algorithms, key-management changes.
PROCESS: review assumptions -> update entities/rules -> rerun validation -> version -> recompute hash.
PROVENANCE: preserve original URL, revision date and review notes.

14. AI_CONSUMPTION
INPUT: protocol description, parties, credentials, key material metadata, messages, assumptions.
OUTPUT: typed knowledge graph, security-property claims, validation findings, unresolved assumptions.
RULE: never infer protocol security from primitive correctness alone.
RULE: never expose private keys, shared secrets or live session keys in semantic outputs.
RULE: distinguish mathematical definitions from deployment recommendations.

END FLOW ALGEBRA