Security

Elydora's layers cover cryptographic integrity, access control, and guidance for key handling.

Cryptographic Stack

Ed25519 (RFC 8032) — All agent signatures use Ed25519 elliptic curve signatures, providing 128-bit security with fast signing and verification.
SHA-256 — Used for payload hashing, chain hashing, receipt hashing, and Merkle tree construction.
JWKS (RFC 7517) — Elydora's public signing keys are published in standard JSON Web Key Set format for independent verification.

Key Management

Agent Keys

Each agent has its own Ed25519 key pair. The private key is held exclusively by the agent and never transmitted to Elydora. Only the public key is registered.

Private keys should be stored in environment variables or a secrets manager
Never commit private keys to version control
Rotate keys by registering a replacement agent and revoking the old key
Use a unique key per agent; do not share keys between agents

Key Generation

The SDKs and CLI take the private key as the base64url-encoded 32-byte Ed25519 seed and register the base64url public key:

bash

node -e "
const { generateKeyPairSync } = require('node:crypto');
const { privateKey, publicKey } = generateKeyPairSync('ed25519');
console.log('private key seed:', privateKey.export({ format: 'jwk' }).d);
console.log('public key:      ', publicKey.export({ format: 'jwk' }).x);
"

Elydora Server Keys

Elydora signs all Acknowledgement Receipts (EARs) and Epoch Roots (EERs) with its own Ed25519 key. The public keys are available at the JWKS endpoint.

RBAC (Role-Based Access Control)

Elydora grants capabilities to five predefined roles. Each API endpoint requires one capability. See the RBAC page for the matrix.

Transport Security

All API communication uses HTTPS
Session tokens expire after 7 days
Rate limits apply to authentication and operation submission

Replay Protection

Multiple mechanisms prevent operation replay:

TTL enforcement — Operations must be submitted within ttl_ms of their issued_at timestamp.
Nonce uniqueness — Each nonce is tracked per organization and rejected if reused.
Chain hash verification — The prev_chain_hash must match the server's expected value, preventing out-of-order or duplicate submissions.

Agent Lifecycle

Active — Agent can submit operations normally.
Frozen — Agent is temporarily suspended. Operations are rejected with AGENT_FROZEN. Can be reactivated via POST /v1/agents/:agent_id/unfreeze.
Revoked — Agent is permanently invalidated. Operations are rejected with AGENT_REVOKED, and a revoked key with KEY_REVOKED. Irreversible.

Data Integrity

Operation records are immutable once accepted. The chain hash mechanism ensures that any modification, deletion, or reordering of records is detectable. Epoch roots provide periodic bulk verification anchors.