How the encryption works

A chain of keys, from your document to your passkey

Steek is built on one promise: only you and the people you choose can open a file — never us. This page explains the chain of keys that makes that true, without exposing private implementation details.

Start secure workspace

Visual workflow

The document moves, the keys stay local

Follow the secure handoff from local encryption to verified recipient open. The loading dots show the locked package in transit while the readable file and the keys that open it stay on user devices.

  1. 01 Encrypt

    Document becomes a sealed package

    The browser turns the readable file into encrypted bytes before upload starts.

    The readable file never leaves

  2. 02 Wrap keys

    Access is bound to recipient identity

    The document key is wrapped for authorized recipients instead of being sent in the clear.

    Keys remain sealed

  3. 03 Deliver

    The locked package travels safely

    Steek moves only the locked package, its expiry rules, and the delivery record.

    Locked package in transit

  4. 04 Verify

    Recipient opens locally after passkey proof

    The recipient proves identity, unwraps access on their device, and views the document locally.

    Verified local open

Locked package in transit

The chain of keys

Every lock is opened only by the next key in the chain

Your document is locked by a key, that key is locked by your account key, and your account key is locked by your passkey. Nothing readable — and no key that could open it — is ever stored where we could reach it.

Link 01

Each document gets its own key

Your browser encrypts the file with a one-time AES-256-GCM key before anything is uploaded. Only encrypted bytes ever leave your device; the readable file never does.

Link 02

That key is sealed to your identity

The document key is locked with post-quantum hybrid encryption (X25519 + ML-KEM-768) to your account's public key, and stored only in that locked form. We hold the locked key; we cannot open it.

Link 03

Your private key is sealed by your passkey

Your account key is sealed shut, and only a secret living inside your passkey can open it — Face ID, Touch ID, Windows Hello, or a hardware key. That secret never leaves the device, and we never receive it.

Link 04

Any of your passkeys opens everything

Every passkey you add keeps its own sealed copy of the same account key. Lose one device and the rest still open every document — your access is never tied to a single point of failure.

Opening a file

What happens when you open a confidential document

Each step runs on your own device. Keys exist in memory only long enough to open one document, and nothing readable ever touches our servers.

01 Prove it is you

A passkey check releases a device-only secret

A passkey assertion with Face ID, Touch ID, Windows Hello, or a security key produces a secret that exists only inside that authenticator — pick any of your passkeys.

02 Unseal your key locally

Your account key is opened in browser memory

That secret unseals your account key in this device's memory, and nowhere else. Our servers only ever hold the sealed, unreadable version.

03 Decrypt, then wipe

The file opens on your device and keys are erased

Your account key unwraps the document key, the file is decrypted locally, and every key is zeroized from memory right after — while the access is recorded for audit.

Our vocabulary

The Morrive family, in plain words

A few names appear across the product. Here is what each one means and how they fit together.

Steek

Dutch and Scots “steek”: to latch, to close, to stitch shut.

The zero-knowledge confidential-document delivery product—the app you are using. Every document is encrypted to the recipient's own keys and can be opened only with their passkey, so it stays sealed to everyone else, including us.

Mitome

Japanese 認め (mitome), a personal seal or hanko: acknowledgement, to recognize.

The shared identity and attestation authority behind Steek—passkeys, verification, and notary. One trusted identity and attestation layer that Steek and future products federate through, so recognition and proof are consistent everywhere.

Coming soon

Uniment

From “muniment,” a document kept as evidence of legal right or title, softened by dropping the M.

An upcoming secure dataroom and document-custody product. It will extend the same identity and attestation trust to whole collections of records, not just single deliveries.

.stk

Steek's encrypted file format and extension.

Not a normal file. Every delivered document is packaged and encrypted client-side into a .stk container—AES-256-GCM content with hybrid post-quantum wrapped keys—openable only by the intended recipient. It is the zero-knowledge artifact itself, not a file with a lock bolted on.

How they fit together

One trust layer, shared across products

Steek delivers, and it trusts Mitome for identity and attestation. Uniment, when it arrives, will extend that same trust to datarooms. A .stk file is the encrypted artifact that flows between them—sealed by Steek, addressed to a Mitome-verified recipient.

Steek, Mitome, and Uniment are all part of the Morrive group.

Visit morrive.com

Zero-knowledge by design

We hold the locks, never the keys

Steek keeps opening files simple while the protection model stays post-quantum ready, lets any of your passkeys decrypt, expires or revokes access, and preserves audit evidence — all without us ever seeing your documents or your keys.

Register