$CHAIN Auction
Someone copies your backup file. The file is encrypted — a string of bytes with no obvious structure. They take it home, point a cracking rig at it, and wait. If the key-derivation function protecting that file is weak, they walk into your identity. Your messages, your contacts, your cryptographic self — all accessible from a stolen blob on a cloud drive.
Self-sovereign identity has an honest problem. If the private key lives only on the user's device, and the device is lost, the identity is lost. No central party can reset it. No support line can recover it. Without some form of backup, the benefit of decentralized identity is paid for with the risk of catastrophic key loss. But a backup that is easy to crack trades one failure mode for a worse one.
Zentalk's answer is a two-layer cryptographic backup architecture: PBKDF2-SHA256 with 600,000 iterations for general key derivation, and Scrypt (N=215, r=8, p=1) — a memory-hard function requiring approximately 32 MiB per derivation — for the E2EE key backup envelope that protects the user's identity keys. The backup is designed to be useful only to the user who created it, resilient against any brute-force attack realistic over the next decade, and portable across any storage medium without introducing a trusted third party.
The Constraint
A backup of a private key is, by definition, a copy of something sensitive. If the backup is stolen, the adversary has the private key. If the backup is too hard for the user to recover, it is useless. The design target is a backup that:
- Can be stored on any medium — cloud drive, USB stick, paper wallet — without trusting that medium.
- Requires a passphrase the user can memorize or record securely.
- Is computationally infeasible to brute-force even with substantial resources.
- Is usable by the legitimate user with modest effort on modest hardware.
Meeting all four requires careful choice of key-derivation function — and for the backup envelope specifically, a memory-hard one.
Two Functions, Two Roles
Zentalk does not use a single KDF for everything. Each function is matched to the security profile of the operation it protects.
PBKDF2-SHA256:
Used for general key derivation — mesh backup encryption, phone authentication key derivation, IndexedDB master key — at 600,000 iterations. The 600,000 iteration count produces approximately 200 ms of computation on 2024 hardware, imperceptible to users but computationally prohibitive at brute-force scale. PBKDF2's CPU-bound cost scales linearly with iteration count and requires negligible memory.
Scrypt:
Used for the E2EE key backup envelope — the single most security-critical derivation in Zentalk. Scrypt is memory-hard: every derivation requires both CPU time and a large block of RAM (approximately 32 MiB in Zentalk's configuration). This memory requirement is the key property. An attacker cannot run thousands of derivations in parallel on a single GPU, because the device does not have terabytes of memory. The attack scales by what hardware can afford in both compute and memory, and memory is the expensive axis.
This is not a redundant choice. PBKDF2 is the established, audited standard for CPU-bound key stretching. Scrypt raises the cost of GPU and ASIC-based brute-force attacks by orders of magnitude — at the cost of higher legitimate-use memory. The backup envelope justifies that cost because it protects an identity that may be used for decades.
The Parameters
Zentalk's backup envelope derivation uses Scrypt with the following parameters, per the 2026 whitepaper:
- N: 215 = 32,768 (CPU/memory cost factor).
- r: 8 (block size).
- p: 1 (parallelization factor).
- Memory: approximately 32 MiB per derivation.
- Output: 32 bytes (256 bits), feeding the wrapping AES-256-GCM key.
- Salt: 32 random bytes generated at backup creation time.
For general key derivation contexts (mesh backup encryption, phone auth, IndexedDB master key), PBKDF2-SHA256 runs at 600,000 iterations — the OWASP 2023 recommendation — producing roughly 200 ms of computation on modern hardware.
The Brute-Force Reality
Scrypt's memory requirement fundamentally changes the attack economics. Where PBKDF2 can be parallelized across thousands of GPU cores — each core needs only negligible memory — Scrypt forces each parallel attempt to allocate approximately 32 MiB of RAM. An attacker attempting 1,000 parallel guesses requires 32 GiB of GPU memory, solely for the derivation.
Against a strong passphrase — six randomly chosen words from a 2,048-word list, for example — the passphrase space is approximately 266. Even at a rate of one billion guesses per second, the average exhaustive search would take longer than the age of the universe. Scrypt's memory cost makes one billion guesses per second physically implausible without extraordinary hardware investment.
Against a weak passphrase, no key-derivation function saves you. The math is unforgiving about low-entropy passphrases. Zentalk's backup flow enforces minimum passphrase entropy and encourages randomly generated passphrases from a standard wordlist precisely because the whole security model collapses if the user picks "summer2024."
The Wrapping Construction
The derived 32-byte key does not directly encrypt the private key. It wraps an intermediate key that encrypts the private key using AES-256-GCM. This indirection allows the passphrase to be changed without re-encrypting the underlying identity: changing the passphrase re-derives a new wrapping key, re-encrypts the intermediate key, and leaves the private key itself untouched.
The wrapped payload includes the salt, the Scrypt parameters (N, r, p — so they can be increased in a future version without breaking existing backups), the GCM nonce, and the GCM ciphertext. The complete backup is typically a few hundred bytes, small enough to encode as a QR code or a short text string.
Storage Options
Because the backup is cryptographically protected by the passphrase, it can be stored anywhere. The provider holds ciphertext, cannot decrypt it, and has no claim on the user's identity. Common options include:
- Cloud storage: Dropbox, iCloud, Google Drive.
- Physical media: USB drives, encrypted external disks.
- Paper wallet: The backup printed as a QR code, stored physically, immune to online breaches.
- Distributed among trusted parties: Shamir secret sharing can split the passphrase across multiple parties, so a majority subset can jointly reconstruct it. Zentalk supports this for high-value identities.
The cryptographic protection is the same regardless of storage medium. This is the correct place to put trust: in mathematics, not in infrastructure.
Recovery Flow
Restoring from backup on a new device is straightforward. The user opens Zentalk on the new device, selects "Restore from backup," provides the backup file or QR code, and enters the passphrase. The client runs Scrypt with the parameters recorded in the backup, derives the wrapping key, decrypts the intermediate key, and reconstructs the private key on the new device.
The derivation takes roughly 100 ms on current hardware. The user perceives a brief pause and then sees their full contact list and group memberships sync back. Old messages remain inaccessible — forward secrecy ensures this — but the identity, contact fingerprints, and session state return intact.
No Recovery Backdoor
There is no "forgot passphrase" option that bypasses the derivation. If the user loses the passphrase, the backup is unrecoverable. This is not a failure of design. It is the exact property that makes the backup safe.
No Custodian:
The Zentalk team cannot recover the identity. A court order cannot compel recovery. A support line cannot reset access. The passphrase is the only input that makes recovery mathematically possible. No entity outside the user's control holds any part of the key.
Users are expected to record the passphrase somewhere durable and safe. Zentalk's guidance emphasizes this repeatedly during backup creation. The cost of the occasional lost identity is paid in exchange for the guarantee that identities are cryptographically owned — not custodied, not recoverable by others, not subject to administrative override.
The Design Philosophy
The choice of Scrypt for the E2EE backup envelope and PBKDF2-SHA256 for general key derivation reflects a deliberate calibration. Not every derivation requires the full cost of memory-hard computation. But for the backup protecting an identity that may be used for decades, Zentalk applies the strongest cost model available without external dependencies.
A backup that is safe today but trivially crackable in 2030 is a liability. Zentalk's parameters are chosen to remain credible through the useful lifetime of the identity — measured in decades, not years. The Scrypt memory requirement in particular is difficult to make obsolete: memory costs are an architectural constraint, not a Moore's Law variable. The 32 MiB cost per guess today imposes the same structural bottleneck five years from now.
Architecture is the only defense. The passphrase is yours. The math enforces it.
Thanks & Best Regards Zentachain Team!
