TTTPS — Byzantine Audit API

Capabilities

What the engine does, end to end.

Detection, the lattice commitment pipeline, the audit query surface, and Prometheus metrics — all converging on a single Ed25519 commitment check.

Attack Detection Matrix

Thirteen attack classes — replay, drift, forgery, flood, ordering, Sybil, GPS spoofing, BGP/DNS, and more — each reduced to a commitment mismatch and logged with attack_type, agent_id, ctx_id, and timestamp.

Lattice Pipeline

A lattice-coded commitment pipeline binds payload and Roughtime chain_digest into a single cryptographic hash, signed with Ed25519. Every attack ultimately converges here.

Audit API

Query the Byzantine trail over any context and window via GET /audit — totals, ratio, and per-type attack breakdown, verifiable with the published public key.

Prometheus Metrics

Per-type attack counters and Byzantine ratio exposed at GET /metrics — drop straight into your existing observability stack.

Thirteen attack classes. One commitment check.

Replay, drift, forgery, flood, ordering, Sybil, GPS spoofing, BGP, DNS — every one of them collapses to the same place: an Ed25519 commitment mismatch no one can forge without the issuer key.

Detection

Attack Detection Capability Matrix

All detected attacks are logged with attack_type, agent_id, ctx_id, and timestamp. Query via GET /audit.

Attack	Detection Mechanism	Lattice Layer	Log Field
Token Replay Reuse of a previously valid PoT token	seen_tokens HashMap — duplicate token hash detected on verify. ✅ Live.	Application	`REPLAY`
Timestamp Drift NTP manipulation, clock skew injection	±60s window check against server time; Roughtime chain_digest bound into lattice commitment — any timestamp deviation causes commitment mismatch. ✅ Live.	chain_digest → FORGE	`DRIFT` / `FORGE`
Signature Forgery Fake issuer, tampered token body	Ed25519 signature verification against published pubkey — computationally infeasible to forge without issuer private key. ✅ Live.	Ed25519	`FORGE`
Flood / DDoS Request rate abuse, resource exhaustion	Per-IP and per-agent rate limiting (requests/min); excess requests rejected with 429. ✅ Live.	Application	`FLOOD`
Ordering Attack Out-of-sequence token submission	Fleet cross-reference — token sequence validated across agent set. ✅ Live.	Application	`ORDERING`
Cross-Pool Replay Token from Pool A submitted to Pool B	Context-bound cryptographic commitment — cross-pool commitment mismatch is computationally infeasible to conceal under standard cryptographic assumptions. ✅ Live.	Commitment	`FORGE`
Sybil Attack Multiple fake agent IDs from same node	Service context commitment binding — each context has a unique cryptographic key; cross-context token reuse fails verification. ✅ Live.	Commitment	`FORGE`
GPS Spoofing Falsified satellite time signals	Roughtime chain spread violation → commitment diverges when timestamp differs across sources. Multi-source Roughtime chains ≥3 operator-independent servers (int08h · roughtime.se · txryan), nonce-chained median per draft-ietf-ntp-roughtime-19 §5.4. ✅ Live.	chain_digest → FORGE	`FORGE`
NTP Injection Rogue NTP server, synchronized clock bias	Roughtime chain_digest is lattice-committed alongside payload — manipulated timestamp shifts chain_digest, breaking Ed25519 signature. Full Roughtime cross-validation live: roughtime_k=3, chain_digest bound into Ed25519 commitment. ✅ Live.	chain_digest → Ed25519	`FORGE`
BGP Hijacking Route manipulation, man-in-the-middle	Intercepted tokens cannot be re-signed without issuer private key — any modification invalidates Ed25519 signature. ✅ Live.	Ed25519	`FORGE`
DNS Poisoning Redirected API endpoint, fake issuer	Issuer pubkey is pinned and published out-of-band; tokens from any other key fail Ed25519 verification. ✅ Live.	Ed25519	`FORGE`
SDN Flow Manipulation Packet reordering via SDN controller	ORDERING cross-reference detects sequence anomalies; lattice integrity layer recovers partial data corruption. ✅ Live.	Lattice + ORDERING	`ORDERING`
Protocol Violation Malformed token, missing fields	Schema validation on all fields; multi-layer ECC detects bit-level corruption. ✅ Live.	ECC	`INVALID`

Lattice Pipeline

All attacks ultimately converge to a commitment mismatch, caught at the Ed25519 layer.

Input Payload (P)
  └─ Lattice-coded commitment pipeline (proprietary)
      └─ Context commitment (ctx_id bound)
          └─ Lattice_Commitment (cryptographic hash over payload + chain_digest)
              └─ Ed25519 signature

API

Query the trail. Export the metrics.

Operator-independent verification: anyone with the published public key can replay the audit trail. Metrics drop into your existing stack.

Audit Log — GET /audit

curl "https://api.kenosian.com/audit?ctx_id=<ctx_id>&window=3600" \
  -H "X-API-Key: <your-api-key>"

{
  "ctx_id": "dlr-poc",
  "window_secs": 3600,
  "total_requests": 142,
  "byzantine_total": 3,
  "byzantine_ratio": 0.021,
  "attack_breakdown": {
    "REPLAY":   2,
    "DRIFT":    1,
    "FORGE":    0,
    "FLOOD":    0,
    "ORDERING": 0,
    "INVALID":  0
  }
}

Prometheus — GET /metrics

tttps_attack_total{type="replay"}   2
tttps_attack_total{type="drift"}    1
tttps_attack_total{type="forge"}    0
tttps_byzantine_ratio               0.021
tttps_valid_count                   139

Quick Start

Generate, verify, audit — four calls.

API access by request. The same engine that runs the case studies above runs live on api.kenosian.com.

Request API Access →

# API access by request — contact peter@kenosian.com

# 1. Health check
curl https://api.kenosian.com/health

# 2. Generate PoT token
curl -X POST https://api.kenosian.com/pot/generate \
  -H "X-API-Key: <your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{"agent_id":"<agent_id>","ctx_id":"<ctx_id>"}'

# 3. Verify + Byzantine detection
curl -X POST https://api.kenosian.com/pot/verify \
  -H "X-API-Key: <your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{"token":"<token>","agent_id":"<agent_id>","ctx_id":"<ctx_id>"}'

# 4. Audit report
curl "https://api.kenosian.com/audit?ctx_id=<ctx_id>&window=3600" \
  -H "X-API-Key: <your-api-key>"

Trust Mark

TTTPS

Verifiable
WHEN

certified

“TTTPS-certified” — the time-integrity standard (proposed)

A proposed trust mark for verifiable when: a system that can produce a tamper-rejecting record of when its events and the actions above them happened. Conditional on TTTPS being adopted as the standard, with Kenosian as the root of trust.

Illustrative mark for explanation only. Any certification authority, mark, or “certified” status is proposed and conditional (“could / if adopted”), and would operate under the Kenosian root — not a present-day certification program.