Staging — blog preview only.
Skip to content

Share file, deep link, and machine-handoff passphrase

Scheduled

5 min read By NT²

Ciphertext and the secret that opens it should not travel as one convenient email. NT² splits carriers—file or link—from OOB passphrase delivery, and treats Strong as machine-handoff.

Share file, deep link, and machine-handoff passphrase

Claim: carrier and secret are different channels

Share passphrase ≠ master password drew the crypto boundary: Mode B/C packages open with a share passphrase, never the vault unlock root.

This essay is the handoff mechanics behind that boundary.

A Mode B/C share is two deliveries that must not collapse into one:

  1. The package carrier — ciphertext as a .nt2share file, or as a hosted / deep-linked payload (/?m= and related link shapes).
  2. The share passphrase — a separate secret, preferably on a different channel (call, in person, passphrase QR, image save, text share that is not the same email as the file).

The claim: file and link are carriers for sealed packages; OOB delivers the passphrase; Strong passphrase tier is machine-handoff entropy—not a memorable phrase you speak over the phone.

Vault-to-vault Mode A does not use this model—see peer connection is not a phone contact. This post is for recipients who may never install NT², or who should receive a disposable package instead of a lasting peer relationship.

Constraint: one email with file + password is not dual-channel

Convenience loves a single message: “Here’s the file; password is attached.” That pattern is how encrypted zips fail in the wild.

If the passphrase rides with the ciphertext, interception gets both. Dual-channel is not theater. It is the difference between stealing a blob and opening a blob.

If Strong is marketed as speakable, users will choose weak memorable strings under a “strong” label. High-entropy machine-handoff secrets are awkward to dictate. That awkwardness is the point. A shorter speakable tier can exist as an explicit weaker choice—not as the definition of Strong.

If deep links embed the passphrase in the URL, referrers, screenshots, and proxy logs become key exfil. Links may carry package identifiers and ciphertext references. The passphrase stays OOB unless the product is deliberately building a weaker “secret in URL” mode—and must not pretend that mode is Strong.

If .nt2share is treated like a PDF attachment anyone can open without a secret, Share becomes email with extra steps. The file is ciphertext. Opening still needs the share passphrase (or a vault Inbox path that still respects Accept).

If “forgot passphrase” emails reconstruct the package key from account login, Mode B/C grew an oracle. Losing the passphrase fails closed—same honesty as unlock reset refusal.

Design: .nt2share, /?m=, and OOB passphrase UI

Mode B and Mode C share one cryptographic story: share passphrase → PBKDF2 under a share-link domain label → AES-GCM package. Delivery differs.

CarrierWhat movesWho opens it
Encrypted link / deep linkURL into hosted or inline package (/?m= QR/copy paths)Browser decrypt page and/or vault Receive → Inbox; needs share passphrase
.nt2share fileFile via USB, AirDrop, download, OS share sheetImport / Inbox / standalone decrypt; needs share passphrase
flowchart TB
  subgraph package [Sealed package]
    CT[Ciphertext fields / items]
  end
  subgraph carriers [Carriers]
    File[.nt2share]
    Link["/?m= deep link"]
  end
  subgraph oob [OOB passphrase]
    Copy[Copy]
    Text[Text share]
    PQR[Passphrase QR]
    Img[Save image]
  end
  CT --> File
  CT --> Link
  SP[Share passphrase] --> oob
  File -.->|different channel| SP
  Link -.->|different channel| SP

Protect / OOB on compose. When the sender enables protection, the product seeds OOB handoff UI: copy the passphrase, share it as text through a channel that is not the file email, show a passphrase QR, or save an image. The ciphertext carrier is chosen separately—download .nt2share, present a link, or both.

Strong = machine-handoff. The Strong passphrase tier is high-entropy and meant to move machine-to-machine (scan, paste from a password field, image). It is not a Crockford speakable code you read aloud as the definition of “strong.” Speakable short codes, if offered, stay an explicit weaker tier with honest UX—not Strong in disguise.

Deep link is a carrier, not a vault unlock. /?m= and related universal link shapes get ciphertext to a browser or into Receive triage. They do not embed master passwords. They should not embed Strong passphrases as query decoration.

Inbox still asks Accept for vault recipients. A file or link that lands in a vault stages through Receive / Inbox. Accept into vault re-encrypts into the recipient’s envelopes. Until then it is staged ciphertext—consistent with relay / local Inbox.

Outbox still tracks hosted life. Links with TTL and revoke remain sender-visible—see revoke what you already sent. A USB file that already copied off-device will not always be remotely killable; the product should not lie about that.

Trade-off: more steps, narrower interception

Dual-channel handoff costs friction. Senders juggle a file or link plus a passphrase path. Strong secrets are hard to dictate on a call—so people must use QR, paste, or image, or choose a weaker speakable tier knowingly.

Recipients without NT² still get a browser decrypt path. Recipients with NT² get structured Accept into slots—not a mystery PDF forever in Downloads. Stories like encrypted link with expiry and USB stick beats email carry the human moment; this essay is the channel split those moments rely on.

We accept the friction because one-channel “encrypted” attachments taught the industry the wrong lesson: encryption theater with the key taped to the box.

What we refuse

We refuse share passphrase = master password. Unlock root never opens Mode B/C packages—and never appears in OOB passphrase UI as the suggested secret.

We refuse Strong-as-speakable marketing. Strong is machine-handoff entropy; speakable codes are a separate, weaker choice when offered.

We refuse passphrase-in-URL as the Strong path. Deep links carry packages; OOB carries secrets.

We refuse “forgot share passphrase” reconstruction from account ownership. Lose the passphrase, lose that handoff.

We refuse treating .nt2share as plaintext-with-a-fancy-extension. The file is a sealed package.

Close: four essays, one cross-vault arc

This series opened with who you encrypt to—peer connections, not phone contacts. It covered what still exists after send—outbox and revoke. It separated legacy delay from password recovery—delayed legacy release. It closes on how Mode B/C bytes and secrets move—file, link, and machine-handoff passphrase.

Together with the primers share passphrase ≠ master password and relay indexes ciphertext; Inbox stays local, the boundary stays small to say: unlock opens your vault; a share passphrase opens one package; peer keys open one addressed handoff; time-delayed legacy opens only when inactivity says it may—and never because a provider held a second key.

If you want handoffs that keep ciphertext and secrets on different channels, explore NT² Vault.

Last updated 2026-12-13

Related stories