​

The TimeChain Standard: Cryptographic Protocols for Trustless Collaborative Documentation

​

Abstract

​

1. Introduction

​

1.1 Motivation

​

1.2 Design Principles

1. Zero Trust Architecture: Servers witness operations but cannot forge, modify, or suppress evidence
2. Cryptographic Non-Repudiation: Every action carries digital signatures that mathematically bind users to their operations
3. Tamper-Evident Chaining: Operations form directed acyclic graphs where modifications break cryptographic proofs
4. Performance Parity: Protocol overhead maintains sub-50ms P95 latency comparable to existing platforms
5. Independent Verification: Third parties verify chains without accessing platform infrastructure
6. Selective Disclosure: Privacy-preserving audit enables verification without revealing all content

​

1.3 Threat Model

• Malicious platform operators attempting to forge audit trails
• Compromised administrators with database access
• Users attempting to repudiate their actions
• Man-in-the-middle attacks on operation streams
• Selective operation suppression or reordering

• Client endpoint compromise
• Social engineering attacks
• Denial of service
• Side-channel attacks on cryptographic implementations

​

2. The VEST Protocol

​

2.1 Overview

​

2.2 Protocol Architecture

Operation Chain Structure:

Genesis ──→ Op₁ ──→ Op₂ ──→ Op₃
             ↑       ↑       ↑
             │       │       └── Hash(Op₂ ‖ content ‖ sig_user ‖ sig_server ‖ timestamp)
             │       └────────── Hash(Op₁ ‖ content ‖ sig_user ‖ sig_server ‖ timestamp)
             └────────────────── Hash(Genesis ‖ content ‖ sig_user ‖ sig_server ‖ timestamp)

Each operation contains:
- Parent hash(es): Links to causal predecessors
- Content: Document mutation (plaintext in VEST, encrypted in CIPHER-VEST)
- User signature: Ed25519 signature over operation hash
- Server signature: Server witness attestation
- Timestamp proof: Roughtime proof from distributed authorities
- Merkle proof: Inclusion proof in periodic tree snapshots

​

2.3 Cryptographic Construction

H = BLAKE3(parent_hashes ‖ lamport_clock ‖ payload ‖ metadata)

σ_user = Ed25519.Sign(sk_user, H)

σ_server = Ed25519.Sign(sk_server, H ‖ σ_user ‖ verification_metadata)

T = Roughtime.Aggregate([T₁, T₂, T₃])  // Three independent authorities

Tree builds over operation hashes at regular intervals (hourly)
Proof size: O(log n) for n operations
Verification: O(log n) time complexity

​

2.4 Chain Verification

function verify_VEST_chain(operations):
    previous_hash = GENESIS_HASH

    for op in operations:
        // Verify hash continuity
        if op.hash != BLAKE3(op.parents ‖ op.clock ‖ op.payload):
            return INVALID("Hash mismatch")

        // Verify parent exists
        if not all_parents_exist(op.parents, previous_ops):
            return INVALID("Broken chain")

        // Verify user signature
        if not Ed25519.Verify(pk_user, op.hash, op.sig_user):
            return INVALID("Invalid user signature")

        // Verify server signature
        if not Ed25519.Verify(pk_server, op.hash, op.sig_server):
            return INVALID("Invalid server witness")

        // Verify timestamp
        if not Roughtime.Verify(op.timestamp_proof):
            return INVALID("Invalid timestamp")

        // Verify Lamport clock monotonicity
        if op.clock <= max_parent_clock(op.parents):
            return INVALID("Clock violation")

        previous_hash = op.hash

    return VALID

• Tamper-evident: Modifying any operation breaks subsequent hashes
• Non-repudiation: User signatures bind operations to identities
• Temporal proof: Roughtime prevents backdating
• Server accountability: Server signatures create witnessing trail

​

2.5 Performance Characteristics

• Client signature generation: 2ms
• Network transit: 8ms
• Server verification: 5ms
• Chain append: 2ms
• Timestamp proof (async): 8ms
• Merkle update: 2ms
• Redis persist: 3ms
• Network return: 8ms
• Total: 38ms

• 100,000 operations/sec per relay node
• Horizontal scaling through consistent hashing on document ID
• Linear capacity growth with nodes

• ~2KB per operation (including signatures and proofs)
• 1M operations = 2GB
• Compression ratio: ~3:1 with zstd
• Cold storage: S3 for operations older than 30 days

​

3. The AEGIS Protocol

​

3.1 Overview

​

3.2 Zero-Knowledge Circuit

Private Inputs:
- user_private_key: User's signing key
- document_id: Target document identifier
- access_token: Permission credential
- timestamp: Current time

Public Inputs:
- user_public_key_hash: Hash of user public key
- document_commitment: Commitment to document
- permission_proof: Proof of valid permission
- timestamp_range: Acceptable time window

Constraints:
C₁: hash(derive_public(user_private_key)) = user_public_key_hash
C₂: commit(document_id) = document_commitment
C₃: verify_token(access_token, document_id, user_private_key) = true
C₄: timestamp ∈ timestamp_range

Proof: π = Groth16.Prove(constraints, private_inputs, public_inputs)

• Constraints: ~5,000
• Proof generation: 200-400ms (client-side)
• Proof verification: 5-10ms (server-side)
• Proof size: ~192 bytes (Groth16)

​

3.3 Selective Disclosure

Encrypted for auditor:
E_audit = Encrypt(auditor_pk, {
    user_id: user_id,
    document_id: document_id,
    access_time: timestamp,
    access_type: READ/WRITE/SHARE
})

Commitment for server:
C_audit = Commit({user_id, document_id, access_time, access_type}, blinding_factor)

Consistency proof:
π_consistency = ZK.Prove(E_audit decrypts to value committed in C_audit)

• Verify consistency proof (learns nothing)
• Add commitment to VEST chain
• Store encrypted record for auditor

• Retrieve encrypted records
• Decrypt with private key
• Verify VEST chain integrity
• Generate audit reports

​

3.4 Integration with VEST

AEGIS_Operation {
    zk_proof: π_access,
    commitments: {user, document, timestamp},
    VEST_reference: hash_of_VEST_operation,
    encrypted_audit: E_audit,
    consistency_proof: π_consistency
}

• VEST chain: Document operations (content modifications)
• AEGIS chain: Access events (who accessed what)
• Cross-references: AEGIS operations link to VEST operations
• Verification: Both chains independently verifiable

​

3.5 Performance Characteristics

• Client proof generation: 250ms (first access)
• Network transit: 8ms
• Server ZK verification: 8ms
• VEST chain append: 2ms
• Audit record encryption: 2ms
• Total: 270ms (first access)
• Subsequent access: <50ms (proof caching)

• 50,000 access verifications/sec per node
• ZK verification is bottleneck
• Batch verification possible (10ms for 10 proofs)

​

4. The CIPHER-VEST Protocol

​

4.1 Overview

​

4.2 Order-Preserving Encryption

Position Encryption:
- Plaintext position: p ∈ [0, n]
- OPE encryption: c = OPE.Encrypt(k_ope, p)
- Property: p₁ < p₂ ⟺ OPE.Encrypt(k_ope, p₁) < OPE.Encrypt(k_ope, p₂)

Full encryption for recovery:
- AES-GCM encryption: e = AES.Encrypt(k_aes, p)
- Client decrypts: p = AES.Decrypt(k_aes, e)

Combined structure:
EncryptedPosition {
    ope_value: c,           // Comparable without key
    full_encrypted: e,      // Decryptable with key
    key_fingerprint: H(k)   // Verify correct key
}

• OPE reveals: Relative ordering of positions
• OPE hides: Exact position values, document content
• Acceptable trade-off: Ordering necessary for CRDT merge

​

4.3 Homomorphic CRDT Rules

function merge_encrypted(op1, op2):
    // Determine causal relationship
    if op1.happens_before(op2):
        return [op1, op2]  // Sequential
    if op2.happens_before(op1):
        return [op2, op1]  // Sequential

    // Concurrent operations - apply CRDT rules
    match (op1.type, op2.type):
        (INSERT, INSERT):
            // Compare OPE positions (no decryption)
            if op1.position.ope_value < op2.position.ope_value:
                return [op1, op2]
            else:
                return [op2, op1]

        (DELETE, INSERT):
            return [op1]  // Delete wins

        (INSERT, DELETE):
            return [op2]  // Delete wins

        (DELETE, DELETE):
            return [op1]  // Idempotent

        (FORMAT, FORMAT):
            // Last-writer-wins by Lamport clock
            if op1.lamport_clock > op2.lamport_clock:
                return [op1]
            else:
                return [op2]

• Deterministic: All clients converge to same state
• Encrypted: Server never sees plaintext
• Efficient: O(1) comparison using OPE

​

4.4 Dual-Layer Structure

{
    // CIPHER layer
    encrypted_content: AES.Encrypt(doc_key, content),
    ope_position: OPE.Encrypt(ope_key, position),
    operation_type: INSERT | DELETE | FORMAT,
    causal_metadata: {parent_ops, lamport_clock},

    // VEST layer
    operation_hash: BLAKE3(above),
    user_signature: Ed25519.Sign(user_key, operation_hash),
    server_signature: Ed25519.Sign(server_key, operation_hash),
    timestamp_proof: Roughtime.Proof(),
    merkle_proof: MerkleTree.Proof()
}

• CIPHER properties: Encryption integrity, OPE consistency
• VEST properties: Hash chain, signatures, timestamps
• Both layers independently verifiable

​

4.5 Performance Characteristics

• Client encryption (AES + OPE): 3ms
• Client signature: 2ms
• Network transit: 8ms
• Server CIPHER verify: 3ms
• Server VEST verify: 5ms
• Server merge (OPE compare): 4ms
• Server witness: 3ms
• Redis persist: 3ms
• Network return: 8ms
• Total: 39ms

• 80,000 operations/sec per node
• OPE comparison overhead vs plaintext: ~10%
• Encryption overhead: ~5%

​

5. Comparative Analysis

​

5.1 Security Properties

​

5.2 Performance Impact

​

5.3 Implementation Complexity

• VEST: 9 months (6 engineers)
• AEGIS: 12 months (8 engineers)
• CIPHER-VEST: 18 months (12 engineers)

• VEST: Protocol design, cryptographic engineering
• AEGIS: Zero-knowledge circuit design, proof system expertise
• CIPHER-VEST: Homomorphic cryptography, CRDT theory, both VEST and CIPHER

​

6. Threat Analysis

​

6.1 Attack Vectors

• VEST: Server can suppress operations but cannot forge signatures or modify chain
• AEGIS: Server cannot learn access patterns even with full database access
• CIPHER-VEST: Server cannot decrypt content even with full database access

• Cannot repudiate signed operations (digital signatures)
• Cannot backdate operations (distributed timestamps)
• Cannot modify others’ operations (signature verification fails)
• Cannot forge server witness (separate key)

• DTLS 1.3 provides transport security
• Man-in-the-middle cannot modify operations (signature verification)
• Replay attacks prevented by sequence numbers and timestamps

​

6.2 Limitations

• Server sees all content (no content privacy)
• Chain grows linearly (storage scaling)
• Cannot hide access patterns

• Proof generation overhead (200-400ms)
• Complex ZK circuit maintenance
• Requires trusted setup for Groth16

• OPE leaks position ordering
• Cannot fully hide document structure
• Complex key management (document keys, OPE keys)

​

6.3 Mitigations

• Periodic pruning of non-semantic operations
• Cold storage for historical operations
• Merkle snapshots reduce verification cost

• Batch verification of signatures and proofs
• Parallel operation processing
• Async timestamp service (non-blocking)

• Hardware security modules for server keys
• Key rotation with forward secrecy
• Distributed key generation for ZK trusted setup

​

7. Deployment Considerations

​

7.1 Migration Strategy

• Run TimeChain protocols alongside existing WebSocket implementation
• Feature flag to enable per-customer
• Measure performance impact in production
• Beta with 10 customers

• Enable for new documents (existing documents stay on legacy)
• Monitor error rates and latency
• Rollback capability via feature flags

• Migrate existing documents to TimeChain
• Deprecate legacy WebSocket for audit features
• Maintain fallback for compatibility

​

7.2 Operational Requirements

• UDP port allocation (DTLS 1.3)
• Roughtime server connectivity (3 independent authorities)
• HSM integration for server keys
• Redis cluster for operation chains
• S3 for cold storage

• Operation latency (P50, P95, P99)
• Chain verification failures
• Signature verification errors
• Timestamp proof failures
• Merkle tree inconsistencies

• Key rotation schedule (annually)
• Certificate renewal
• Trusted setup updates (AEGIS)
• Performance optimization

​

7.3 Client Requirements

• WebAssembly for cryptographic operations
• Ed25519 via WebCrypto or WASM
• ZK proof generation via WASM (AEGIS)

• Native cryptographic libraries
• Background operation signing
• Certificate pinning

• Native performance for proof generation
• Hardware security module access

​

8. Standards Compliance

​

8.1 Cryptographic Standards

• FIPS 140-2: Cryptographic module validation
• NIST SP 800-90A: Random number generation
• RFC 8032: Ed25519 signature algorithm
• RFC 5869: HKDF key derivation

​

8.2 Protocol Standards

• RFC 8446: TLS 1.3 (via DTLS 1.3)
• RFC 9000: QUIC transport (design inspiration)
• Roughtime Protocol: Distributed timestamp standard

​

8.3 Compliance Frameworks

• Article 32: Security of processing (cryptographic proof)
• Article 5: Data minimization (AEGIS zero-knowledge)

• § 164.312(b): Audit controls (VEST)
• § 164.312(e)(1): Transmission security (DTLS)

• CC6.1: Logical access (AEGIS)
• CC7.2: System monitoring (VEST audit trails)

​

9. Future Work

​

9.1 Protocol Extensions

• Replace Ed25519 with CRYSTALS-Dilithium
• Replace BLAKE3 with quantum-resistant hash
• Transition path for existing chains

• STARKs (transparent setup, larger proofs)
• Bulletproofs (no setup, slower verification)
• Halo 2 (recursive proofs)

• Replace OPE with FHE schemes
• Eliminate position ordering leakage
• Performance penalty: 100-1000x slower

​

9.2 Research Questions

1. Can we reduce ZK proof generation to <100ms while maintaining security?
2. Can we achieve O(1) chain verification with cryptographic accumulators?
3. Can we eliminate OPE leakage while maintaining CRDT merge performance?
4. Can we extend AEGIS to multi-party computation for collaborative access control?
5. Can we use blockchain consensus for byzantine fault tolerance in VEST chains?

​

9.3 Ecosystem Development

• Protocol specifications (RFC format)
• Reference implementations (Rust, TypeScript)
• Verification tools (CLI, web interface)
• Client libraries (multiple languages)

• Formal verification of protocol properties
• Security proofs for cryptographic constructions
• Performance analysis and optimization
• Integration with existing systems

​

10. Conclusion

​

Appendix A: Notation

• H(x): Cryptographic hash function (BLAKE3)
• σ = Sign(sk, m): Digital signature (Ed25519)
• Verify(pk, m, σ): Signature verification
• E(k, m): Symmetric encryption (AES-256-GCM)
• Commit(m, r): Cryptographic commitment

• op: Operation
• H: Hash value
• pk, sk: Public and private keys
• σ: Signature
• π: Zero-knowledge proof
• T: Timestamp proof

• ‖: Concatenation
• ∈: Element membership
• ⊆: Subset relation

​

Appendix B: References

1. Merkle, R. “Protocols for Public Key Cryptosystems.” IEEE Symposium on Security and Privacy, 1980.
2. Lamport, L. “Time, Clocks, and the Ordering of Events in a Distributed System.” Communications of the ACM, 1978.
3. Bernstein, D. et al. “High-speed high-security signatures.” Journal of Cryptographic Engineering, 2012.
4. Groth, J. “On the Size of Pairing-based Non-interactive Arguments.” EUROCRYPT 2016.
5. Boldyreva, A. et al. “Order-Preserving Symmetric Encryption.” EUROCRYPT 2009.
6. Shapiro, M. et al. “Conflict-free Replicated Data Types.” SSS 2011.
7. Roughtime Protocol Specification. https://roughtime.googlesource.com/roughtime
8. Blake3 Specification. https://github.com/BLAKE3-team/BLAKE3-specs