Cryptographic Properties

Underlying Algorithms

The SAID specification mandates cryptographic hash functions with approximately 128 bits of cryptographic strength to ensure collision resistance. The primary algorithm used in KERI/ACDC implementations is:

• Blake3-256: A 256-bit cryptographic hash function providing 128-bit security strength
• Alternative algorithms may be supported through CESR's cryptographic agility, but Blake3-256 is the standard for vLEI credentials

Security Properties

SAIDs provide several critical security guarantees:

Collision Resistance: The probability of two different data structures producing the same SAID is computationally infeasible (approximately 2^-128 for Blake3-256). This ensures that any copy of data that verifies against a SAID can be assumed identical to any other copy verifying to the same SAID.

Pre-image Resistance: Given a SAID, it is computationally infeasible to construct data that hashes to that SAID. This prevents attackers from creating fraudulent data structures that match legitimate SAIDs.

Tamper Evidence: Any modification to the data structure—no matter how small—produces a completely different SAID. This makes tampering immediately detectable upon verification.

Cryptographic Binding: The SAID creates an unbreakable cryptographic link between the identifier and the content, eliminating the need for external registries or resolution mechanisms.

Key/Output Sizes

For Blake3-256 (the standard algorithm):

• Raw digest size: 32 bytes (256 bits)
• CESR text encoding: 44 characters (Base64 URL-safe)
• CESR binary encoding: 33 bytes (1-byte derivation code + 32-byte digest)
• Security strength: 128 bits (collision resistance)

Data Format & Encoding

CESR Encoding Format

SAIDs are encoded using CESR (Composable Event Streaming Representation), which provides dual text-binary encoding with composability properties. The CESR encoding includes:

1. Derivation Code: A prefix indicating the hash algorithm used
2. Digest Value: The actual cryptographic hash output

Text and Binary Representations

Text Domain (Base64 URL-safe):

EAco5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M

Breakdown:

• E: Derivation code for Blake3-256 digest
• Aco5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M: Base64-encoded 32-byte digest

Binary Domain:

• First byte: 0x12 (derivation code for Blake3-256)
• Following 32 bytes: Raw digest output

Derivation Codes

Common CESR derivation codes for SAIDs:

• E: Blake3-256 digest (standard for KERI/ACDC)
• F: Blake2b-256 digest (alternative)
• G: Blake2s-256 digest (alternative)
• H: SHA3-256 digest (alternative)
• I: SHA2-256 digest (legacy, not recommended)

SAID Generation Protocol

The SAID derivation process follows a precise algorithm:

Step 1: Reserve Field Space

Allocate a fixed-length field in the serialization for the SAID. The length is determined by the chosen digest algorithm and CESR encoding (44 characters for Blake3-256 in text domain).

Step 2: Insert Dummy String

Fill the SAID field with placeholder characters (#, ASCII 35) of exact target length. For a 44-character SAID field:

{
  "d": "############################################",
  "name": "Alice",
  "age": 30
}

Step 3: Compute Digest

Generate the cryptographic digest of the serialization containing the dummy string using the specified algorithm (Blake3-256). The serialization must be in canonical form with deterministic field ordering.

Step 4: CESR Encode

Encode the digest using CESR, which prepends the derivation code indicating the cryptographic algorithm.

Step 5: Replace Dummy

Substitute the dummy string with the computed SAID to create the final serialization:

{
  "d": "EAco5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
  "name": "Alice",
  "age": 30
}

Verification Process

To verify a SAID:

1. Extract the SAID value from the data structure
2. Replace the SAID field with dummy characters of the same length
3. Recompute the digest of the modified serialization
4. Compare the computed digest to the extracted SAID
5. If they match, the data is authentic and unmodified

Usage in KERI/ACDC

In Key Event Logs (KELs)

SAIDs appear in multiple contexts within KEL events:

Event Digest Field (d): Every KERI event includes a SAID in its d field, making the event self-addressing. This enables:

• Content-addressable event storage
• Cryptographic chaining between events (the p field references the prior event's SAID)
• Tamper-evident event logs

Schema References (s): Events reference schemas by their SAIDs, ensuring schema immutability and version-specific validation.

Seal References: When events anchor external data through seals, they reference that data by SAID.

In ACDC Credentials

ACDCs make extensive use of SAIDs for graduated disclosure:

Top-Level SAID (d): Every ACDC has a SAID identifying the entire credential structure.

Section SAIDs: Major sections (attributes a, edges e, rules r, schema s) can be represented either as:

• Compact form: Just the SAID of the section
• Expanded form: The full section content

Example compact ACDC:

{
  "v": "ACDC10JSON00011c_",
  "d": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
  "i": "EpDA1n-WiBA0A8YOqnKrB-wWQYYC49i5zY_qrIZIicQg",
  "s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
  "a": "EFgnk_c08WmZGgv9_mpldibRuqFMTQN-rAgtD-TCOwbs"
}

Here, the a field contains only the SAID of the attributes section, enabling selective disclosure where the holder can later provide the full attributes and prove they match the committed SAID.

In Transaction Event Logs (TELs)

TELs use SAIDs to reference:

• The management TEL that governs a credential registry
• Individual credential instances being issued or revoked
• The KEL events that anchor TEL events

Common Usage Patterns

Compact Disclosure: Present only SAIDs initially, revealing full content progressively as trust develops.

Chained Credentials: ACDCs reference other ACDCs by SAID in their edge sections, creating verifiable credential graphs.

Schema Versioning: Each schema version has a unique SAID, preventing schema mutation attacks.

Content Addressing: SAIDs enable universal retrieval of specific data versions without centralized registries.

Verification Procedures

Verifying SAID-based data structures:

1. Extract the SAID: Retrieve the SAID value from the d field
2. Identify the algorithm: Parse the CESR derivation code
3. Reconstruct the identifiable basis: Replace the SAID with dummy characters
4. Canonicalize: Ensure deterministic serialization (field ordering, no whitespace)
5. Compute digest: Apply the identified hash algorithm
6. Compare: Verify the computed digest matches the extracted SAID

Related Primitives

Self-Addressed Data (SAD)

A SAD is the data structure from which a SAID is derived. The relationship is:

• The SAID is derived from the SAD
• The SAID is embedded within the SAD
• The SAD is the "saidified data" after SAID insertion

Every SAID has a corresponding SAD, but not all data structures are SADs (only those containing SAIDs).

Cryptographic Digests

SAIDs are a specialized application of cryptographic hash functions with the unique property of self-referentiality. While standard digests are computed over external data, SAIDs are computed over data that includes the digest itself (via the dummy string mechanism).

CESR Primitives

SAIDs are one type of CESR primitive. Other related primitives include:

• Signers: Private keys that create signatures
• Verfers: Public keys that verify signatures
• Digers: Standard (non-self-referential) digests
• Cigar/Siger: Signature attachments

Composition Patterns

Nested SAIDs: ACDCs contain multiple SAIDs at different levels:

• Top-level credential SAID
• Section SAIDs (attributes, edges, rules)
• Schema SAID
• Referenced credential SAIDs in edges

This creates a hash tree structure analogous to Merkle trees, where:

• The top-level SAID serves as the root hash
• Section SAIDs are intermediate nodes
• Signing the compact form commits to the entire tree
• Verification follows proof-of-inclusion patterns

SAID Chains: In credential graphs, SAIDs create cryptographic links:

Credential A (SAID: E123...) 
  → references Credential B (SAID: E456...)
    → references Credential C (SAID: E789...)

This enables verifiable provenance chains without expanding all credentials.

Implementation Considerations

Canonical Serialization

SAID computation requires deterministic serialization:

• Field ordering: Must be consistent (insertion order in KERI/ACDC)
• No whitespace: Compact JSON without spaces or newlines
• Consistent encoding: UTF-8 for text, specific byte ordering for binary

Failure to maintain canonical form produces different SAIDs for logically identical data.

Algorithm Selection

While CESR supports multiple hash algorithms, Blake3-256 is strongly recommended for KERI/ACDC because:

• High performance (faster than SHA-2 and SHA-3)
• Strong security properties (128-bit collision resistance)
• Standardized in vLEI ecosystem governance frameworks
• Post-quantum resistant (as a hash function)

Dummy String Length

The dummy string must exactly match the final SAID length:

• Blake3-256 in text domain: 44 characters
• Blake3-256 in binary domain: 33 bytes

Incorrect dummy length produces invalid SAIDs.

Recursive SAID Computation

For nested structures (like ACDCs with multiple sections), SAIDs must be computed recursively from innermost to outermost:

1. Compute SAIDs for leaf-level sections
2. Embed those SAIDs in parent structures
3. Compute parent SAIDs incorporating child SAIDs
4. Continue upward to the root SAID

This ensures that the top-level SAID cryptographically commits to all nested content.

Performance Optimization

SAID computation can be optimized by:

• Caching: Store computed SAIDs to avoid recomputation
• Incremental hashing: Use streaming hash APIs for large data
• Parallel computation: Compute independent section SAIDs concurrently

Security Considerations

Algorithm Agility: While Blake3-256 is current standard, CESR's derivation codes enable algorithm migration if vulnerabilities are discovered.

Collision Attacks: With 128-bit security strength, collision attacks require approximately 2^64 operations (birthday paradox), which is computationally infeasible with current technology.

Pre-image Attacks: Finding data that produces a specific SAID requires 2^256 operations for Blake3-256, which is astronomically infeasible.

Quantum Resistance: Hash functions like Blake3 are generally considered quantum-resistant, as Grover's algorithm only provides quadratic speedup (reducing 256-bit security to 128-bit, which remains secure).

Performance Considerations

Caching: Store computed SAIDs to avoid recomputation when the same data is processed multiple times.

Streaming: For large data structures, use streaming hash APIs that process data incrementally rather than loading entire structures into memory.

Parallel Processing: When computing SAIDs for multiple independent sections (e.g., ACDC attributes and rules), compute them concurrently.

Common Pitfalls

Incorrect Dummy Length: Using a dummy string that doesn't match the final SAID length produces invalid results.

Non-Canonical Serialization: Including whitespace, using wrong field ordering, or inconsistent encoding produces different SAIDs for logically identical data.

Wrong Recursion Order: Computing parent SAIDs before child SAIDs in nested structures produces incorrect results.

Algorithm Mismatch: Using a different hash algorithm than indicated by the CESR derivation code during verification.

Testing Recommendations

Round-Trip Testing: Verify that SAID generation and verification are inverse operations.

Canonicalization Testing: Ensure that logically equivalent data structures (with different whitespace, field ordering) produce the same SAID after canonicalization.

Tamper Detection Testing: Verify that any modification to the data structure (even single-bit changes) produces a completely different SAID.

Cross-Implementation Testing: Verify that SAIDs computed by different implementations (Python, TypeScript, Rust) match for identical data.