Technical

D4TE Technical Specification

This document provides a technical overview of the D4TE (Decay 4-Tooth Encryption) protocol for security researchers, auditors, and developers. It covers cryptographic primitives, key derivation hierarchy, message encryption, and security properties.

Cryptographic Primitives

Algorithm Suite

Function	Algorithm	Parameters
Symmetric Encryption	`AES-256-GCM`	256-bit key, 96-bit nonce, 128-bit tag
Key Derivation	`HKDF-SHA256`	Per RFC 5869
Password KDF	`Argon2id`	m=64 MiB, t=3, p=1, 256-bit output
Hash	`SHA-512/SHA-512-256`	512/256-bit output
MAC	`HMAC-SHA256`	256-bit tag
KEM	`ML-KEM-768`	NIST FIPS 203, Level 3

Security Levels

All primitives are designed for at least 128-bit security against quantum adversaries (formal proofs are classical-ROM to date; QROM analysis is in progress):

AES-256: 128-bit post-quantum (Grover's algorithm halves effective key length)
ML-KEM-768: NIST Level 3 (~128-bit quantum)
SHA-256/512: 128/256-bit (preimage), 128/256-bit (collision)

The 4-Tooth Key Hierarchy

D4TE derives keys through four distinct "teeth," each representing an independent security requirement:

Tooth 1: Group Master Key (GMK)

prehash = SHA-512("phrase-prehash-v1" || phrase || "rn-nw-v1" || rn_nw || "nid-v1" || network_id)

salt = network_id || "master-v1"

GMK = Argon2id(prehash, salt, m=64MiB, t=3, p=1)

The GMK anchors all network-specific keys to the passphrase. The random network nonce rn_nw ensures identical passphrases produce different keys across networks.

Tooth 2: Domain Keys

k_root = SHA-512/256(GMK || network_id || "kroot-v1")

k_sender_dom = HKDF(salt="kdf-domains-v1", ikm=GMK, info="sender-dom-v1" || user_id)

slant_seed = HKDF(salt="slant-seed-dom-v1", ikm=k_root, info="slant-seed-v1" || user_id)

Domain keys bind keys to specific users and purposes, preventing key confusion attacks.

Tooth 3: Device-Bound Keys (Spice v1)

k_device_root = HKDF(
    salt = "d4te-device-root-v1",
    ikm = k_root || device_secret,
    info = device_id
)

k_sender_dom_spiced = HKDF(
    salt = "d4te-sender-dom-spiced-v1",
    ikm = k_sender_dom || cycle_secret,
    info = ""
)

The device_secret is generated locally and stored on the device: on iOS it is protected by the Keychain and Secure Enclave; on Android it lives in app-private storage, with hardware-backed protection on our roadmap. The cycle_secret is distributed via ML-KEM-768 encapsulation.

Tooth 4: Backstop Ratchet

backstop_initial = HKDF(
    salt = "backstop-init-v2",
    ikm = k_device_root || cycle_secret,
    info = network_id || peer_stream_id
)

backstop_{n+1} = SHA-512/256(backstop_n || "backstop-step-v1" || counter_be_u64)

The backstop ratchet provides forward secrecy at the cycle boundary, with a per-message one-way advancement inside a cycle. Each advancement irreversibly destroys previous backstop values, and rotating a cycle destroys that cycle's keys.

Message Encryption

Envelope Format

Envelope {
    version: u8,              // Protocol version (0x31 for v1)
    suite: u8,                // Cipher suite identifier
    key_id: u32,              // Epoch/key rotation identifier
    counter: u64,             // Monotonic message counter
    timestamp: i64,           // Unix milliseconds
    nonce: [u8; 12],          // Random AES-GCM nonce
    ciphertext: Vec<u8>,      // AES-256-GCM encrypted payload
    token_ext: Vec<u8>,       // Sender authentication token
    tag2: [u8; 32],           // Secondary integrity tag
    backstop_tag: [u8; 16],   // Backstop verification tag
}

Additional Authenticated Data (AAD)

AAD = version || suite || key_id || counter || timestamp || group_id || sender_id

All envelope metadata is authenticated but not encrypted, enabling routing while preventing tampering.

Security Properties

Forward Secrecy

Level: Cycle boundary, with a per-message one-way ratchet inside a cycle
Mechanism: Backstop ratchet advances after each message; cycle rotation destroys the prior cycle's keys
Property: Compromise of current keys cannot decrypt messages from destroyed prior cycles

Post-Compromise Security (Roadmap)

Status: Not yet delivered. Cycle rotation today re-seals to the same long-term device key. Device-key rotation is tracked on our roadmap; until it ships, rotating credentials limits exposure but is not a full post-compromise recovery mechanism.

Key Indistinguishability

Property: Keys appear random to attackers without full key chain
Basis: HKDF security under random oracle model

Authentication

Mechanism: token_ext proves sender membership; tag2 provides integrity
Property: Messages cannot be forged from outside the group; authenticity is membership-scoped (any member can derive any member's domain key)

Test Vector (Abbreviated)

// Input:
phrase = "correct horse battery staple"
rn_nw = 0x00112233445566778899aabbccddeeff
network_id = 0x12345678123412341234123456789abc
user_id = "user-alice-001"

// Output:
GMK = 902846ab2dc48fcf9a42e52a1eec978e9a68ea6ad1d70fbc7d6675f51e565368
k_root = 85cb7008e3bf540d93326abb7322db950e26d49316025f1dbf709652941f377d
k_sender_dom = b102c2aa7c58d71f8d7547f31fc82daf5286049fa3df15be1673b2ff7ea103f1

Limitations and Open Problems

Metadata: D4TE encrypts content but not routing metadata (sender, recipient, timing)
Formal Proofs: Security analysis is informal; formal proofs in standard models remain future work
Large Group Scaling: Cycle rotation is O(n) in group size; tree-based schemes could improve this
Multi-Device Sync: Device-bound secrets complicate multi-device support

Key Takeaways

D4TE uses a four-level key hierarchy requiring passphrase, device, time, and message-specific components
All cryptographic primitives are designed for 128-bit post-quantum security
Cycle-boundary forward secrecy via a one-way backstop ratchet
ML-KEM-768 Spice protocol provides phrase-compromise resistance
Complete test vectors enable independent implementation verification

← Previous Quantum-Resistant Security Back to All White Papers