Cryptographic Properties

Underlying Algorithms

KERI supports multiple cryptographic algorithms for key-pair generation, with algorithm selection indicated by derivation codes in CESR encoding:

Ed25519 (EdDSA):

• Curve: Twisted Edwards curve edwards25519
• Private key size: 32 bytes (256 bits)
• Public key size: 32 bytes (256 bits)
• Signature size: 64 bytes (512 bits)
• Security level: ~128 bits (quantum: ~64 bits)
• Properties: Deterministic signatures, fast verification, small keys

ECDSA secp256k1:

• Curve: Koblitz curve secp256k1 (used in Bitcoin)
• Private key size: 32 bytes (256 bits)
• Public key size: 33 bytes compressed, 65 bytes uncompressed
• Signature size: Variable (typically 70-72 bytes DER encoded)
• Security level: ~128 bits (quantum: ~64 bits)
• Properties: Widely deployed, hardware support available

ECDSA secp256r1 (P-256):

• Curve: NIST P-256 curve
• Private key size: 32 bytes (256 bits)
• Public key size: 33 bytes compressed, 65 bytes uncompressed
• Security level: ~128 bits (quantum: ~64 bits)
• Properties: NIST standardized, FIPS compliant

Security Properties

Collision Resistance: The one-way function used to derive public keys from private keys must be collision-resistant, meaning it's computationally infeasible to find two different private keys that produce the same public key.

Discrete Logarithm Problem: Security of elliptic curve key-pairs relies on the computational hardness of the discrete logarithm problem on the chosen curve.

Entropy Requirements: KERI requires at least 128 bits of cryptographic strength for key generation, typically achieved through cryptographically secure pseudo-random number generators (CSPRNGs) or true random number generators.

Post-Quantum Considerations: While individual key-pairs are vulnerable to quantum attacks (Shor's algorithm), KERI's pre-rotation mechanism provides post-quantum security by rotating keys before quantum computers can break them. The pre-rotated key commitment uses cryptographic digests (hash functions) which remain quantum-resistant.

Key Generation Process

The typical key-pair generation workflow in KERI:

1. Entropy Collection: Generate high-entropy random seed (bran/salt)
2. Private Key Derivation: Apply key derivation function to seed
3. Public Key Derivation: Apply elliptic curve point multiplication to private key
4. Verification: Validate key-pair mathematical relationship
5. Storage: Securely store private key, publish public key

Data Format & Encoding

CESR Encoding Format

KERI uses CESR (Composable Event Streaming Representation) to encode key-pairs with derivation codes that specify the cryptographic algorithm:

Text Domain (Base64 URL-safe):

[derivation_code][base64_encoded_public_key]

Example Ed25519 public key:

DXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148

• D: Derivation code for Ed25519 public key
• Xq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148: Base64-encoded 32-byte public key

Binary Domain: The same key-pair is encoded in binary with a binary derivation code prefix, maintaining composability across text/binary domains.

Derivation Codes

Common KERI derivation codes for key-pairs:

• D: Ed25519 public verification key (44 characters total)
• 1AAA: Ed25519 private signing key (88 characters total)
• E: ECDSA secp256k1 public verification key
• 1AAB: ECDSA secp256k1 private signing key
• B: Ed25519 public key (basic self-addressing)
• 0B: Ed25519 seed (for deterministic key generation)

The derivation code serves dual purposes:

1. Algorithm identification: Specifies which cryptographic algorithm to use
2. Length indication: Determines how many characters/bytes to parse

Qualified Representation

All cryptographic material in KERI appears in fully qualified representation, meaning the derivation code is always prepended. This makes primitives self-describing and enables:

• Cryptographic agility: Multiple algorithms can coexist
• Stream parsing: Primitives can be parsed without external context
• Composability: Text and binary representations are interchangeable

Usage in KERI/ACDC

In Establishment Events

Inception Event:

{
  "v": "KERI10JSON00011c_",
  "t": "icp",
  "d": "EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148",
  "i": "EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148",
  "s": "0",
  "kt": "1",
  "k": ["DXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148"],
  "nt": "1",
  "n": ["EYAfSVPzhzaU6JR2nmwyZdi0d8JZAoTNZH3ULvS6b5CM"],
  "bt": "0",
  "b": [],
  "c": [],
  "a": []
}

• k field: Current public key(s) from authoritative key-pair(s)
• n field: Digest of next (pre-rotated) public key(s)
• kt field: Current signing threshold
• nt field: Next signing threshold

Rotation Event:

{
  "v": "KERI10JSON00011c_",
  "t": "rot",
  "d": "EYAfSVPzhzaU6JR2nmwyZdi0d8JZAoTNZH3ULvS6b5CM",
  "i": "EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148",
  "s": "1",
  "p": "EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148",
  "kt": "1",
  "k": ["DYAfSVPzhzaU6JR2nmwyZdi0d8JZAoTNZH3ULvS6b5CM"],
  "nt": "1",
  "n": ["ETNZH3ULvS6bYAfSVPzhzaU6JR2nmwyZfi0d8JZ5s8bk"],
  "bt": "0",
  "b": [],
  "br": [],
  "ba": [],
  "a": []
}

• k field: New current public key(s) (previously committed in n)
• n field: New digest of next public key(s)
• Rotation reveals the pre-rotated key-pair and commits to the next one

Multi-Signature Scenarios

For multi-sig AIDs, multiple key-pairs are used with threshold requirements:

{
  "kt": "2",
  "k": [
    "DXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148",
    "DYAfSVPzhzaU6JR2nmwyZdi0d8JZAoTNZH3ULvS6b5CM",
    "DTNZH3ULvS6bYAfSVPzhzaU6JR2nmwyZfi0d8JZ5s8bk"
  ]
}

• kt: "2": Requires 2 signatures from the 3 key-pairs
• Each controller manages their own private key
• Signatures are attached as indexed signatures indicating which key-pair signed

Verification Procedures

Signature Verification Workflow:

1. Extract public key: Retrieve the appropriate public key from the KEL's current key state
2. Parse signature: Extract the signature attachment from the event message
3. Verify signature: Use the public key to cryptographically verify the signature over the event content
4. Check threshold: For multi-sig, verify sufficient signatures meet the threshold

Key State Verification:

1. Replay KEL: Process all establishment events from inception
2. Track key rotations: Follow the chain of pre-rotation commitments
3. Verify pre-rotation: Confirm each rotation reveals a key matching the prior commitment
4. Establish current state: Determine the current authoritative key-pair(s)

Delegation and Hierarchical Key Management

KERI supports delegated identifiers where a parent AID delegates authority to child AIDs:

• Delegator key-pair: Signs the delegation event
• Delegate key-pair: Controls the delegated identifier
• Cooperative delegation: Both delegator and delegate must sign
• Superseding recovery: Parent can rotate child's keys in compromise scenarios

Related Primitives

Cryptographic Digests

Key-pairs are closely related to cryptographic digests (hashes) in KERI:

• Pre-rotation commitments: Digests of next public keys
• Self-addressing identifiers: Digests of inception event data
• Event chaining: Digests link events in the KEL

Common digest algorithms:

• Blake3-256: 32-byte output, quantum-resistant
• Blake2b-256: 32-byte output, widely supported
• SHA3-256: 32-byte output, NIST standard

Digital Signatures

Key-pairs enable digital signatures that provide:

• Authentication: Proves the signer possesses the private key
• Integrity: Detects any modification of signed data
• Non-repudiation: Signer cannot deny having signed

Signature types in KERI:

• Indexed signatures: Include index for multi-sig scenarios
• Witness receipts: Counter-signatures from witnesses
• Controller signatures: Primary signatures on key events

Self-Certifying Identifiers

Key-pairs are the foundation of self-certifying identifiers:

• Basic SCID: Public key directly embedded in identifier
• Self-addressing SCID: Digest of inception data including public key
• Autonomic Identifier (AID): SCID with key rotation capability

The self-certifying property means the identifier cryptographically proves its binding to the key-pair without external verification.

Implementation Considerations

Key Generation Security

Entropy Sources:

• Use CSPRNG (Cryptographically Secure Pseudo-Random Number Generator)
• Prefer hardware RNG when available (TPM, HSM)
• Minimum 128 bits of entropy for security
• Consider key stretching (Argon2, PBKDF2) for password-derived keys

Key Derivation:

• Hierarchical Deterministic (HD) derivation for related keys
• BIP32/BIP39 compatible for cryptocurrency integration
• Salted derivation to prevent rainbow table attacks

Key Storage

Private Key Protection:

• Never transmit private keys over networks
• Encrypt at rest using strong encryption (AES-256-GCM)
• Hardware isolation (HSM, TPM, secure enclave) for high-value keys
• Key splitting for multi-party control scenarios

Univalent vs. Multivalent Architecture:

• Univalent: Key generation and signing co-located
• Multivalent: Distributed key management with delegation
• Bivalent: Nested delegation with layered recovery

Key Rotation Best Practices

Pre-Rotation Strategy:

• Generate next key-pair before current key exposure
• Store pre-rotated keys in higher security than current keys
• Use one-time rotation keys for maximum security
• Implement reserve rotation for long-term key management

Rotation Triggers:

• Scheduled rotation: Regular key lifecycle management
• Compromise detection: Immediate rotation on suspected breach
• Algorithm migration: Transition to stronger algorithms
• Organizational changes: Personnel or infrastructure changes

Performance Optimization

Signature Generation:

• Batch signing: Sign multiple events together when possible
• Hardware acceleration: Use CPU crypto extensions (AES-NI)
• Parallel verification: Verify multiple signatures concurrently

Key Caching:

• Cache public keys from frequently accessed KELs
• Invalidate cache on rotation events
• Use LRU eviction for memory management

Interoperability

Cross-Platform Compatibility:

• Use standard algorithms (Ed25519, ECDSA)
• Follow CESR encoding specifications exactly
• Support multiple derivation codes for algorithm agility
• Implement version negotiation for protocol evolution

Integration Points:

• DID methods: did:keri, did:webs integration
• Verifiable Credentials: ACDC credential signing
• Blockchain anchoring: Ledger-backed witnesses
• Legacy PKI: Certificate-based interop where needed

• Follow CESR specification exactly for encoding
• Support multiple derivation codes for algorithm agility
• Implement version negotiation for protocol evolution
• Ensure compatibility with DID methods (did:keri, did:webs)