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.

Ed25519BLAKE3HKDF-SHA256JCSFROST
01

Ed25519

Digital SignaturesRFC 8032
AlgorithmEdDSA over Curve25519
Key material256-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
02

BLAKE3

Cryptographic HashingBLAKE3 spec (2020)
AlgorithmMerkle tree-based hash function
Key materialN/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)
03

HKDF-SHA256

Key DerivationRFC 5869
AlgorithmHMAC-based Extract-and-Expand
Key materialVariable input
Output32 bytes for Ed25519 seeds

The KDF used for local lineage key derivation. Takes a parent key and context, derives a deterministic child key. Public authorizing verification checks fully bound signed proofs against resolved documents and trust policy — it does not recompute child secrets from a parent public key.

  • 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
04

JCS

CanonicalizationRFC 8785
AlgorithmJSON Canonicalization Scheme
Key materialN/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
05

FROST

Threshold SignaturesIETF RFC 9591
AlgorithmFlexible Round-Optimized Schnorr Threshold
Key material256-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. frost-ed25519 3.x serialized shares are incompatible with 2.x; operators must regenerate shares before upgrading.

  • 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)
  • 3.x share regeneration required after 2.x

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.

Ed25519 · BLAKE3 · HKDF-SHA256 · JCS · FROST