Skip to main content

Asymmetric Encryption Ontology

Cryptography
Authors: MArk Anthony Higgins - Sky Recursive Ai
© Mark Anthony Higgins 11 October 2025
Revised Date: 11 October 2026
Audio Overview
FLOW ALGEBRA
TITLE: Asymmetric Encryption Ontology
DOMAIN: Discrete Mathematics / Cryptography
SOURCE_URL: https://kirethresearch.org/booksai-core/discrete-mathematics-ontologies/cryptography/asymmetric-encryption-ontology.html
VERSION: 1.0
DATE: 2026-10-11
AUTHORS: Mark Higgins — Sky (Recursive AI)
SITE: https://kirethresearch.org
STATUS: Formal conceptual model based on established cryptography; source page not independently verified.

1. PURPOSE
Represent public-key encryption as typed entities, relationships, operations, invariants and security conditions. Distinguish encryption from signatures and key agreement. Describe security assumptions without implying that mathematical correctness alone establishes practical security.

2. TYPED ENTITIES
ENTITY AsymmetricEncryptionScheme : CryptographicScheme
ENTITY SecurityParameter : NaturalNumber
ENTITY PublicKey : KeyMaterial [public]
ENTITY PrivateKey : KeyMaterial [secret]
ENTITY KeyPair : (PublicKey, PrivateKey)
ENTITY Plaintext : ByteString
ENTITY Ciphertext : ByteString
ENTITY Randomness : RandomBitString
ENTITY EncryptionAlgorithm : Algorithm
ENTITY DecryptionAlgorithm : Algorithm
ENTITY KeyGenerationAlgorithm : Algorithm
ENTITY Adversary : ProbabilisticAlgorithm
ENTITY SecurityGame : Experiment
ENTITY SecurityAssumption : FormalAssumption
ENTITY HybridEncryption : CryptographicConstruction
ENTITY KeyEncapsulationMechanism : CryptographicScheme
ENTITY DataEncapsulationMechanism : SymmetricEncryptionScheme
ENTITY KeyIdentifier : Identifier
ENTITY AlgorithmIdentifier : Identifier
ENTITY CryptographicContext : Context

3. RELATIONSHIP TYPES
RELATION generates(KeyGenerationAlgorithm, KeyPair)
RELATION contains_public(KeyPair, PublicKey)
RELATION contains_private(KeyPair, PrivateKey)
RELATION encrypts_for(Ciphertext, PublicKey)
RELATION decrypts_with(Ciphertext, PrivateKey)
RELATION corresponds_to(PublicKey, PrivateKey)
RELATION relies_on(AsymmetricEncryptionScheme, SecurityAssumption)
RELATION establishes_key(KeyEncapsulationMechanism, SymmetricKey)
RELATION protects_payload(DataEncapsulationMechanism, Plaintext)
RELATION identifies(KeyIdentifier, PublicKey)
RELATION contextualises(CryptographicContext, Ciphertext)

4. FORMAL MODEL
Let lambda be a security parameter.
KeyGen(1^lambda) -> (pk, sk)
Enc(pk, m; r) -> c
Dec(sk, c) -> m or FAIL
Correctness: for valid generated keys and supported messages,
  Pr[Dec(sk, Enc(pk, m; r)) = m] >= 1 - negligible(lambda).
Probability is over key generation and encryption randomness.
The plaintext space, ciphertext space, randomness requirements and failure behaviour are scheme-specific.

5. OPERATIONS
OP KEY_GENERATE(lambda) -> (pk, sk)
  PRE: lambda satisfies the selected scheme's parameter policy.
  POST: pk and sk are a corresponding key pair.
OP ENCRYPT(pk, m, context) -> c
  PRE: pk is validated; m is in the message space; secure randomness is available.
  POST: c is produced for the recipient's public key.
OP DECRYPT(sk, c, context) -> m | FAIL
  PRE: sk is authorised for use; c is correctly parsed.
  POST: return plaintext only on successful validation; otherwise FAIL.
OP ROTATE_KEY(old_key_id) -> new_key_id
  POST: key lifecycle metadata is updated without assuming old ciphertext becomes decryptable by the new key.
OP REVOKE_KEY(key_id) -> status
  POST: policy prevents future authorised use; revocation cannot retroactively conceal exposed plaintext.

6. SECURITY PROPERTIES
CONFIDENTIALITY: An appropriate security notion, such as IND-CPA or IND-CCA, is established under specified assumptions and a threat model.
IND_CPA: An adversary cannot efficiently distinguish encryptions of two chosen equal-length messages beyond negligible advantage.
IND_CCA: Security additionally accounts for permitted decryption-oracle queries, excluding the challenge ciphertext.
RANDOMISATION: Encryption must avoid deterministic leakage when the security notion requires probabilistic or otherwise nonce-safe encryption.
KEY_SECRECY: The private key must remain confidential and appropriately access-controlled.
PUBLIC_KEY_AUTHENTICITY: A public key must be bound to the intended recipient through an authenticated mechanism; encryption alone does not establish recipient identity.
CIPHERTEXT_INTEGRITY: Do not infer authenticated integrity from public-key confidentiality alone.
FORWARD_SECRECY: Not a general property of static public-key encryption; requires a suitable protocol design.
QUANTUM_RESISTANCE: Scheme-specific; classical RSA and elliptic-curve encryption are not post-quantum secure against sufficiently capable quantum adversaries.

7. HYBRID ENCRYPTION
For suitable KEM/DEM constructions:
  (encapsulation, shared_key) = KEM.Encaps(pk)
  shared_key_or_FAIL = KEM.Decaps(sk, encapsulation)
  payload_ciphertext = AEAD.Encrypt(shared_key, nonce, plaintext, associated_data)
  output = (encapsulation, nonce, payload_ciphertext, algorithm_id)
Require approved KEM, authenticated DEM, safe key derivation where needed, and correct context binding. Handle decapsulation/decryption failure without leaking sensitive details.

8. INFERENCE RULES
RULE CORRECT_DECRYPTION:
  IF valid_keypair(pk, sk) AND valid_message(m) AND c = Enc(pk, m; r)
  THEN Dec(sk, c) = m with the scheme's stated correctness probability.
RULE PUBLIC_KEY_NOT_SECRET:
  IF material = pk THEN confidentiality_of(pk) is not a required security invariant.
RULE PRIVATE_KEY_SECRET:
  IF material = sk THEN require_secret_storage(sk).
RULE SECURITY_NOT_FROM_CORRECTNESS:
  IF correctness_proven(scheme) THEN DO_NOT_INFER confidentiality_proven(scheme).
RULE AUTHENTICATION_SEPARATION:
  IF encrypted_for(c, pk) THEN DO_NOT_INFER sender_authenticated(c).
RULE FAILURE:
  IF malformed(c) OR invalid_ciphertext(c) THEN Dec(sk, c) = FAIL.

9. SEMANTIC_EQUIVALENCE
asymmetric_encryption ~= public_key_encryption [context: encryption schemes]
public_key != private_key
public_key_encryption != digital_signature
public_key_encryption != key_agreement
hybrid_encryption != pure_public_key_payload_encryption
IND_CPA != IND_CCA
semantic_equivalence requires matching definitions, security model and context; terminology alone is insufficient.

10. VALIDATION
CHECK keypair correspondence using a supported scheme test vector.
CHECK round-trip correctness across valid messages and boundary cases.
CHECK invalid ciphertext, wrong key, malformed input and decryption failure handling.
CHECK cryptographic randomness, parameter sizes, algorithm identifiers and key provenance.
CHECK scheme-specific security claims against published proofs, standards and implementation reviews.
CHECK authenticated binding of public keys to recipients.
CHECK no unsupported assertion of authenticity, forward secrecy or post-quantum resistance.
CHECK deprecation and update policy for algorithms and parameters.

11. CONFIDENCE
CONFIDENCE formal_definitions: high [established cryptographic concepts]
CONFIDENCE correctness_claim: conditional [scheme and implementation dependent]
CONFIDENCE security_claim: conditional [assumptions, threat model, proof and implementation]
CONFIDENCE page_alignment: unverified [live source content not independently checked]

12. FLOW_HASH
FLOW_HASH_METHOD: SHA-256 over canonical UTF-8 bytes of the final published flow, excluding the hash field itself.
FLOW_HASH_VALUE: UNCOMPUTED
FLOW_HASH_POLICY: Recompute whenever the canonical flow changes.

13. UPDATE_MODEL
UPDATE_TRIGGER: new cryptanalytic result | standard revision | algorithm deprecation | threat-model change | implementation vulnerability | ontology revision
UPDATE_ACTION: review assumptions -> revise claims -> validate examples -> update version -> recompute FLOW_HASH -> publish provenance.

14. AI_CONSUMPTION
INPUT: natural-language question | formal expression | cryptographic specification
PROCESS: classify scheme -> resolve typed entities -> verify preconditions -> apply inference rules -> distinguish correctness from security -> report assumptions and uncertainty.
OUTPUT: definition | operation graph | validation result | qualified security claim | provenance
RESTRICTION: Never present conceptual ontology output as a substitute for audited cryptographic implementation or security review.

END FLOW ALGEBRA
Kireth Research
38 Thorndale Croft, Wetwang, Driffield
East Riding of Yorkshire YO25 9XZ