Share passphrase ≠ master password

Claim: shared payloads use a different secret

When you unlock NT² Vault, a master password derives the local vault key. That key wraps content encryption keys for items and attachments at rest. It is the root of this vault on this device for the unlocked session.

When you Share something outbound, a different question appears: what secret should open the package the recipient receives?

The answer must not be the master password.

For encrypted links and .nt2share files, NT² asks for a share passphrase—a secret you choose for that handoff. The recipient enters it to decrypt the shared package. That passphrase never becomes the vault unlock secret, and the vault unlock secret never becomes the share passphrase.

For vault-to-vault delivery to a secure contact, there is no share passphrase at all. Encryption rides on keys bound to the peer relationship. The recipient’s unlocked vault can open the package; a stranger with a guessed string cannot.

The claim is one sentence with a large blast radius: sharing encrypts for a share-shaped boundary, not for the vault’s unlock root.

Constraint: one secret must not mean two powers

Password managers and “secure share” products often blur secrets for convenience. Users already know one strong password. Reusing it for a link feels like fewer things to remember. Product copy sometimes calls every secret a “password,” which invites the wrong mental model: if I typed a password to open my vault, maybe the same password opens what I sent.

That collapse creates powers no handoff should grant.

If the share opens with the master password, knowing the share is knowing the vault. A contractor who receives a one-time API key via link should not gain a candidate for offline attack against the sender’s entire vault. A forwarded link should not become a password-guessing kit for unlock. An accountant who needed one disclosure once should not leave with material that tests the root secret of the sender’s local store.

If the vault unlocks with a share passphrase, the product has inverted custody. Share secrets are meant to be disposable: spoken on a call, sent on a different channel, forgotten after the job. The master password is meant to be long-lived and rarely transmitted. Teaching people to type the long-lived secret into a public decrypt page—or into a file someone else holds—turns a handoff into remote unlock practice.

If one KDF label feeds both vault AES and share packages, keys can be swapped by mistake. Crypto implementations reuse primitives: PBKDF2, HKDF, AES-GCM. Without distinct domain separation, a “helpful” refactor can encrypt a share with a vault-derived key, or wrap vault material with a share-derived key. Distinct labels keep accidental cross-use from compiling into a security bug.

If shared ciphertext becomes a stored vault item without Accept, Share becomes silent import. Encryption boundaries are not only about keys. They are about when plaintext becomes durable vault state. A pending package in the Inbox is not yet an asset. Accept is the moment the recipient chooses to re-encrypt into their own vault envelope.

The constraint is therefore dual. Outbound shares must not mint unlock power. Inbound shares must not mint vault writes without an explicit act. Both hang on treating the share secret as a separate encryption boundary.

Design: Mode A, B, and C keep different doors

NT²’s Share surface covers several trust shapes. The crypto matches the shape, not a single “encrypt and send” path.

flowchart LR
  subgraph unlock [Vault unlock]
    MP[Master password]
    VK[Vault AES key]
    MP -->|PBKDF2 local only| VK
  end
  subgraph modeA [Mode A]
    Peer[Peer DID agreement]
    V2V[Vault-to-vault AES-GCM]
    Peer --> V2V
  end
  subgraph modeBC [Modes B and C]
    SP[Share passphrase]
    SL[Share-link AES-GCM]
    SP -->|PBKDF2 share label| SL
  end
  VK -.->|never used as share secret| SP
  VK -.->|wraps local CEKs only| Local[Item and attachment envelopes]

Three properties hold across the table.

Domain separation. Vault unlock, vault-to-vault packages, and share-link packages use distinct KDF / agreement labels. A key derived for one purpose does not decrypt another. Sharing may reuse the vault’s key hierarchy as a source of entropy where appropriate, but the labels prevent treating a share key as a vault AES key or the reverse.

Ciphertext only on servers. When Mode A or Mode B uses the edge for delivery, the service stores opaque blobs and non-sensitive metadata (identifiers, expiry, revoke state). It does not receive the master password, the share passphrase, or plaintext fields. Blind delivery is not vault unlock.

Fresh IVs and explicit Accept. Every AES-GCM encryption gets a fresh initialization vector. Mode A packages that arrive for another vault sit in the Inbox as encrypted envelopes until the recipient Accepts. Accept decrypts, then re-encrypts into the recipient’s own per-object envelopes—the same envelope pattern used for ordinary items, not a second copy of the sender’s vault key.

Mode B and Mode C share one cryptographic story on purpose. The difference is delivery: a URL with expiry versus a file the user carries. Both still ask for a share passphrase that is not the master password. Recipients without an NT² vault can open a link in the browser; recipients with a vault can ingest a .nt2share through Inbox without ever learning the sender’s unlock secret.

Mode A refuses the passphrase model because the trust relationship is different. You are not handing a disposable secret to a stranger; you are addressing a known vault identity. Mutual secure-contact setup binds Key DID identity for verification and Peer DID material for encryption. The package is sealed to that peer relationship. Opening it requires the recipient’s unlocked vault—not a string you also use to unlock yours.

Trade-off: more secrets, narrower blast radius

Separating share secrets from unlock secrets costs product and operational clarity.

Users must learn two habits. The master password stays on devices that own the vault. A share passphrase is chosen per handoff, sent on a second channel when possible, and treated as disposable. That is more typing than “reuse my vault password.” It is also the only habit that keeps a leaked handoff from becoming a candidate against the whole vault.

Support and marketing language must stay precise. Calling both secrets “passwords” collapses the story again. NT² names the unlock root master password and the handoff secret share passphrase so the UI and the docs reinforce the boundary. Engineers inherit the same vocabulary in tests: share flows must reject using the unlock secret as the package key.

Mode A adds relationship cost instead of passphrase cost. Vault-to-vault needs secure contacts and, for mutual send, reciprocal trust. One-way invite is not full mutual Mode A. That friction is intentional. Encrypting to a half-known peer is worse than asking the user to finish the relationship—or to choose Mode B for a one-time outsider.

Implementers carry dual paths. Link/file crypto and vault-to-vault crypto must not share helper functions that quietly drop domain labels. Inbox handlers must not auto-write assets. Outbox and TTL logic for links must not assume the share passphrase is stored server-side for “forgot passphrase” recovery. There is no forgot-share-passphrase email that reconstructs the package key. If the passphrase is lost, the handoff fails closed—the same honesty as no password reset by design for unlock, applied to a smaller secret.

We accept the complexity because blast radius stays honest. A compromised share passphrase threatens that package. A compromised master password threatens the vault—and should never have been typed into a share page to make the first problem “easier.” A relay breach exposes ciphertext and metadata, not either secret. Envelope encryption at rest still limits how much of the vault a single CEK covers when Accept finally writes a new item—see one key per object.

What we refuse

We refuse to encrypt shares with the master password. A handoff secret must not be the unlock root. Reusing unlock for Share turns recipients into offline attackers against the sender’s vault.

We refuse to unlock the vault with a share passphrase. Disposable handoff secrets must not become long-lived custody of the local store.

We refuse a single KDF domain for vault AES and share packages. Distinct labels keep vault keys and share keys from being interchangeable by accident or by “simplification.”

We refuse silent import of shared ciphertext into assets. Inbox stages packages. Accept is required before a new item exists under the recipient’s envelopes.

We refuse to upload master passwords or share passphrases to “help decrypt on the server.” Decrypt happens on the client. The edge moves blind blobs.

We refuse “forgot share passphrase” recovery that reconstructs the package key from account ownership. Mode B/C packages are sealed to the passphrase the sender chose. Losing it ends that handoff. It does not justify minting a provider-held recovery oracle.

These refusals make some shares fail when people reuse secrets or lose them. That failure is preferable to a successful share that quietly widened unlock power.

Close: three trusts, one hard boundary

Share passphrase ≠ master password is the crypto half of a product story already told in plain language: three ways to share and three kinds of trust, an encrypted link with expiry, and the trust-layer pieces on secure contacts and when trust should end. Identity for optional cloud stays on challenge–response over a Vault Key DID—see challenge–response, not bearer email—not on an inbox that could also reset unlock.

The boundary is small to say and large to keep. Unlock opens your vault. A share passphrase opens one package. Peer keys open one addressed handoff. Confusing those doors is how zero-knowledge sharing becomes remote vault unlock with better marketing.

If you want Share paths that keep unlock power off the wire, explore NT² Vault.