VAULT

Seed phrase protection

Zero-knowledge + Shamir multi-party thresholds: your seed phrase is encrypted in the browser only, and the decryption key is split into N shares where any M recover it. The server sees nothing but ciphertext. This feature is in security review and coming soon.

StatusComing soon

Seed phrase protection has a finalized design and is currently undergoing an independent security review; it is not yet available. This page documents the final design — if the review changes anything, the docs will be updated. Until launch, keep your seed phrase in offline storage and do not store it under any other credential type.

Why seed phrases are different

A seed phrase is the ultimate key to crypto assets: whoever holds the plaintext fully controls the funds, with no reset and no revocation. That is why it is a separate credential class in Tesska, with stricter rules than anything else:

Never brokered — seed-phrase entries cannot be exchanged through the broker and are never delivered to any project or caller.
Zero-knowledge end to end — one step beyond mode B (approval-based): the server never sees plaintext and never holds the complete decryption key either.
No backdoor — Tesska cannot reset or recover it for you. Security rests entirely on cryptography and on how you distribute your shares.

# Seed-phrase entries never take part in brokered access.

POST /v1/login   ->  can never target a seed-vault entry:
                     no short-lived token, no raw delivery,
                     no approval flow. The broker simply does
                     not see this credential class.

Encryption model: in-browser DEK → Shamir shares

All encryption, splitting, and wrapping happens in your browser; the server only ever handles ciphertext:

The seed phrase is encrypted with a random DEK (AES-256-GCM) generated in your browser; the server stores ciphertext only.
The DEK is split with Shamir Secret Sharing into N shares, any M of which reconstruct it (2 ≤ M ≤ N ≤ 16); fewer than M shares reveal nothing about the DEK.
Each share is wrapped to its holder's key and exported as a share file that you distribute yourself — to trustees, across devices, across locations.

# Every step below runs in your browser.
# The server only ever stores ciphertext.

seed phrase
  |- encrypted with a random DEK        AES-256-GCM
DEK
  |- split via Shamir Secret Sharing    N shares, any M reconstruct
                                        (2 <= M <= N <= 16)
each share
  |- wrapped to its holder's key
  |- exported as a share file           you download & distribute

server stores : seed ciphertext only
server never  : sees plaintext / holds the full DEK / joins reconstruction

Recovery flow

Recovery means collecting any M share files and reconstructing in the browser:

Gather any M share files — you do not need all N, and order does not matter.
Select those M files on the recovery page; the client reconstructs the DEK inside your browser.
The reconstructed DEK decrypts the seed ciphertext locally — plaintext exists only in your browser's memory and is discarded after use.
Throughout the process, the server only relays ciphertext and never takes part in reconstruction.

What the server can see

Can see: the seed ciphertext, metadata such as share count and threshold, and audit events (who created or recovered, and when).
Can never see: the seed phrase plaintext, the complete DEK, or any share in plaintext.
Will never do: participate in reconstruction, hold share files for you, or reset/recover on your behalf.

Zero-knowledge is a mathematical guarantee, not a promise.Even if Tesska's servers were fully compromised, an attacker would obtain nothing but undecryptable ciphertext — without M shares, nobody (including us) can reconstruct the DEK.

Keeping your shares safe

You distribute and safeguard the share files yourself; the threshold you pick sets the balance between security and fault tolerance:

A larger M is harder to steal (more shares needed); a larger N − M tolerates more loss. Example, 3-of-5: lose 2 shares and you can still recover; steal 2 shares and they are useless.
Distribute shares across independent trustees, devices, and locations so one incident cannot take out several at once.
Periodically verify that each share file is still usable and each holder still reachable.

Losing more than N − M shares means permanent, unrecoverable loss.Once fewer than M shares remain, the DEK is mathematically impossible to reconstruct; zero-knowledge means Tesska has no backdoor and no recovery path. Choose your threshold carefully before distributing, and treat this as a hard constraint.