Elliptic Curve Cryptography Ontology

FLOW ALGEBRA
ELLIPTIC CURVE CRYPTOGRAPHY ONTOLOGY
Kireth Semantic Library | Discrete Mathematics | Cryptography
Source: https://kirethresearch.org/booksai-core/discrete-mathematics-ontologies/cryptography/elliptic-curve-cryptography-ontology.html
Version: 1.0 | Locale: en-GB | Date: 2026-10-11
Authorship: Mark Higgins — Sky (Recursive AI)
Site: https://kirethresearch.org
Status: Mathematics-based ontology; source page not independently verified.

1. PURPOSE
Represent elliptic-curve cryptography (ECC) as typed mathematical objects, operations, relationships, constraints, verification rules and machine-consumable semantic flows. Distinguish abstract curve arithmetic from specific secure protocols and implementations.

2. TYPED ENTITIES
FiniteField := GF(p) or GF(2^m), with validated field parameters
FieldElement := element of FiniteField
EllipticCurve := nonsingular curve over FiniteField
CurvePoint := affine point (x,y) satisfying curve equation, or point at infinity O
CurveParameters := (field, coefficients, base_point G, subgroup_order n, cofactor h)
Scalar := integer interpreted modulo n for subgroup operations
PrivateScalar := secret d with 1 <= d < n
PublicPoint := Q = [d]G, validated on curve and in intended subgroup
KeyPair := (PrivateScalar, PublicPoint)
Signature := scheme-specific pair or encoding, e.g. ECDSA (r,s)
SharedSecret := scheme-specific result of validated key agreement
HashFunction := approved digest algorithm selected by protocol
Protocol := ECDH | ECDSA | EdDSA | other standardised curve-based construction
SecurityPolicy := curve selection, validation, randomness, side-channel protection, key lifecycle

3. MATHEMATICAL FOUNDATIONS
For a short Weierstrass curve over GF(p), p > 3:
  E: y^2 = x^3 + ax + b (mod p)
  Nonsingularity: 4a^3 + 27b^2 != 0 (mod p)
  E(GF(p)) includes point at infinity O.
Other curve models (e.g. Montgomery, Edwards) have distinct formulas and validation requirements; do not apply short Weierstrass formulas indiscriminately.

4. GROUP OPERATIONS
Identity: P + O = O + P = P
Inverse: P + (-P) = O
Associativity: (P + Q) + R = P + (Q + R)
Commutativity: P + Q = Q + P
Scalar multiplication: [k]P := repeated group addition
Distributivity: [a+b]P = [a]P + [b]P
Composition: [a]([b]P) = [ab]P
Subgroup: [n]G = O; n is the order of G.
For short Weierstrass affine points P != +/-Q:
  lambda = (y_Q-y_P) * (x_Q-x_P)^(-1) mod p
  x_R = lambda^2 - x_P - x_Q mod p
  y_R = lambda*(x_P-x_R) - y_P mod p
For doubling P with y_P != 0:
  lambda = (3*x_P^2+a)*(2*y_P)^(-1) mod p
Exceptional cases require identity/inverse handling; projective implementations use alternative formulas.

5. CRYPTOGRAPHIC FLOWS
KEY_GENERATION:
  input validated CurveParameters and cryptographically secure randomness
  sample secret d uniformly from [1,n-1]
  derive Q = [d]G
  output protected private key d and encoded public key Q
  never expose d or intermediate secrets

ECDH_AGREEMENT (abstract):
  parties generate private scalars d_A, d_B and public points Q_A, Q_B
  validate peer public points according to the selected protocol
  compute S_A = [d_A]Q_B and S_B = [d_B]Q_A
  require S_A = S_B under compatible valid parameters
  derive application keys using a specified KDF and protocol context
  do not use raw point coordinates directly as encryption keys
  authentication is not inherent in unauthenticated ECDH

ECDSA_SIGN (abstract):
  use approved curve, hash, secure per-message nonce k, private d
  R = [k]G; r = x_R mod n; require r != 0
  s = k^(-1)*(z + r*d) mod n; require s != 0
  output (r,s); z is digest-derived integer per standard
  nonce reuse or bias can expose private key

ECDSA_VERIFY (abstract):
  validate public Q and signature ranges 1 <= r,s < n
  w = s^(-1) mod n; u1 = z*w mod n; u2 = r*w mod n
  R = [u1]G + [u2]Q; reject if R = O
  accept iff (x_R mod n) = r
  protocol must define digest processing and encoding

EdDSA:
  separate standardised Edwards-curve signing family
  do not equate EdDSA equations or key formats with ECDSA

6. SEMANTIC RELATIONSHIPS
EllipticCurve IS_DEFINED_OVER FiniteField
CurvePoint IS_ELEMENT_OF EllipticCurve
BasePoint GENERATES Subgroup
PrivateScalar DERIVES PublicPoint
PublicPoint IS_VALIDATED_BY PointValidation
ScalarMultiplication OPERATES_ON CurvePoint
ECDH USES ScalarMultiplication
ECDSA USES ScalarMultiplication AND HashFunction
EdDSA USES EdwardsCurveArithmetic
SecurityPolicy CONSTRAINS KeyGeneration AND Protocol
KeyAgreement PRODUCES SharedSecret
KeyDerivationFunction DERIVES SymmetricKey FROM SharedSecret

7. INFERENCE RULES
IF valid_curve(E) AND valid_base_point(G,n) AND 1<=d<n
THEN Q=[d]G belongs to subgroup generated by G.
IF valid ECDH inputs and compatible parameters
THEN [d_A]([d_B]G)=[d_B]([d_A]G).
IF signature passes scheme-specific verification
THEN signature is valid for supplied public key and message under that scheme;
NOT proof of human identity absent authenticated key binding.
IF ECDSA nonce k is repeated across distinct messages with same private key
THEN private-key compromise may be possible.
IF peer point validation fails THEN reject protocol operation.

8. VALIDATION AND INVARIANTS
- Verify finite-field and curve parameter integrity and nonsingularity.
- Check base point is on curve, nonidentity, and has stated order.
- Validate encoded points and reject invalid or noncanonical encodings as required.
- Enforce subgroup/cofactor rules specific to chosen protocol.
- Use approved parameter sets and established cryptographic libraries.
- Protect secrets with constant-time arithmetic and side-channel controls.
- Enforce fresh, secure nonce generation or standardised deterministic ECDSA.
- Separate encryption, signatures, key agreement and key derivation semantics.
- Reject zero, out-of-range or invalid scalars and malformed signatures.
- ECC is not inherently quantum-resistant.

9. SEMANTIC_EQUIVALENCE
"ECC" ~= "elliptic-curve cryptography" (terminological alias)
"EC point multiplication" ~= "scalar multiplication" (in cryptographic context)
"ECDH" != "ECDSA"
"ECDSA" != "EdDSA"
"elliptic curve" != "elliptic-curve cryptosystem"
"public point" != "authenticated public key"
"shared secret" != "derived symmetric encryption key"
Equivalence is context-scoped, not permission to substitute protocols.

10. CONFIDENCE
mathematical_definitions: 0.99 (established theory)
protocol_generalisation: 0.95 (scheme-specific constraints apply)
source_page_alignment: unverified
implementation_security: not_assessed
Confidence labels are descriptive metadata, not a cryptographic security proof.

11. FLOW_HASH
algorithm: SHA-256
input: canonical UTF-8 representation of final published flow
value: COMPUTE_ON_PUBLICATION
Do not treat this placeholder as a computed digest.

12. UPDATE_MODEL
version: 1.0
change_trigger: revised standard, security guidance, mathematical correction or ontology change
update_sequence: review -> validate -> version -> recompute FLOW_HASH -> publish
preserve: source URL, provenance, change log and prior version references

13. AI_CONSUMPTION
ontology_id: kireth:discrete-mathematics:cryptography:elliptic-curve-cryptography
primary_entity: EllipticCurveCryptography
parent: CryptographyOntology
related: FiniteField, Group, PublicKey, PrivateKey, DigitalSignature, KeyAgreement
machine_tasks: semantic retrieval, mathematical reasoning, protocol classification, constraint checking
safe_use: educational and semantic representation; not deployable cryptographic code
provenance: Kireth Semantic Library URL above

END FLOW ALGEBRA