Specification / Cryptography

Cryptographic Primitives

Five primitives form the trust foundation. Each was chosen for specific properties: no flexibility, no negotiation, no algorithm agility. Fixed at specification time.

Ed25519
BLAKE3
HKDF-SHA256
JCS
FROST
Scroll to illuminate
Ed25519
Digital SignaturesRFC 8032
AlgorithmEdDSA over Curve25519
Key256-bit (32 bytes)
Output512-bit (64 bytes) signature

The sole signature algorithm in OAS. Used for all identity assertions, lineage proofs, DID document signatures, and verifiable credentials. Deterministic signatures, fast verification, compact sizes.

Deterministic: same message + key = same signature
~70,000 verifications/second on commodity hardware
32-byte public keys, 64-byte signatures
No random number generation during signing
Resistant to side-channel attacks by design
BLAKE3
Cryptographic HashingBLAKE3 spec (2020)
AlgorithmMerkle tree-based hash function
KeyN/A
Output256-bit default, extendable

Used for content addressing, integrity checking, and fingerprinting. 3-5x faster than SHA-256 with equivalent security margins. Parallelizable via internal Merkle tree structure.

2-3 GB/s on modern hardware
Parallelizable via Merkle tree
Extendable output: any length
Keyed hashing mode for MAC
Incrementally updatable (streaming)
HKDF-SHA256
Key DerivationRFC 5869
AlgorithmHMAC-based Extract-and-Expand
KeyVariable input
Output32 bytes for Ed25519 seeds

The KDF used for all lineage chains. Takes a parent key and context, derives a deterministic child key. Enables offline verification of the entire lineage chain without contacting any authority.

Two-phase: Extract then Expand
Deterministic: same inputs = same output
Context-binding prevents key reuse
Formally proven in random oracle model
Available in every major crypto library
JCS
CanonicalizationRFC 8785
AlgorithmJSON Canonicalization Scheme
KeyN/A
OutputDeterministic JSON string

Ensures any JSON document has exactly one canonical byte representation. Prevents signature failures from semantically identical but byte-different JSON (whitespace, key ordering).

Deterministic key ordering (Unicode sort)
Normalized numbers (no trailing zeros)
No insignificant whitespace
UTF-8 with minimal escaping
Idempotent: canonical(canonical) = no-op
FROST
Threshold SignaturesIETF draft-cfrg-frost
AlgorithmFlexible Round-Optimized Schnorr Threshold
Key256-bit per share
OutputStandard Ed25519-compatible

Used for MHR entities where M-of-N signers cooperate. Produces standard Ed25519-compatible signatures -- verifiers cannot distinguish single-signer from threshold. Transparent governance upgrade.

M-of-N: any M from N can sign
Output-compatible with Ed25519 verification
Two-round protocol (reducible to one)
No trusted dealer (distributed keygen)
Proactive resharing without changing pubkey

Design Rationale

Why these five, and only these five

Why no algorithm agility?

Algorithm negotiation introduces downgrade attacks. OAS fixes every primitive at specification time. If a primitive is broken, a new spec version replaces it globally.

Why Ed25519 instead of ECDSA?

Deterministic signatures eliminate nonce reuse risk. Faster verification, smaller keys, and constant-time implementations are more widely available.

Why BLAKE3 instead of SHA-256?

3-5x faster, parallelizable, extendable output, and keyed hashing mode. Security margins are equivalent.

Why FROST over Shamir + Schnorr?

FROST produces standard Ed25519-compatible signatures. Verifiers cannot distinguish single-signer from threshold-signed outputs.