Unlocking a local vault is not logging in to the cloud

Most software has trained us to call every act of gaining access a "login." Enter a password, press a button, and something opens. The word is convenient, but it hides an important distinction for an encrypted, local-first vault.

Opening the vault on your device is not the same as authenticating to an optional cloud service.

The first operation answers: Can this device turn the local ciphertext into usable data?

The second answers: Can this vault prove to a remote service that it is the same vault the service already knows?

Those questions involve different secrets, different systems, and different failure modes. Treating them as one event may simplify a diagram or a sign-in screen, but it also encourages the server to become part of the unlock path. For NT² Vault, that would weaken the architecture at exactly the point where the boundary should be clearest.

The constraint hidden inside one word

In a conventional cloud application, "login" usually means authenticating to a server account. The server looks up a user record, verifies a password or delegates to an identity provider, and creates a session. Data access follows because the server controls the data.

A local-first encrypted vault reverses that relationship. The useful copy of the vault is on your device. Its sensitive contents are ciphertext at rest. The device needs a cryptographic key to read them, and that key should be derived locally from your master password. The server does not need to approve that operation because the server is not opening the vault.

If we collapse local unlock and cloud authentication into one generic login, several familiar assumptions begin to creep back in:

• there must be an email address to locate an account;
• the server must know enough to decide whether the password is correct;
• an internet response becomes necessary before local data can open;
• account recovery is expected to restore access to encrypted contents;
• a valid cloud session is mistaken for possession of a decryption key.

Each assumption is normal for cloud-first software. Together, however, they reintroduce the trust that a zero-knowledge vault is meant to remove.

The most dangerous shortcut is a server-held unlock oracle: any stored value or remote endpoint that can help determine whether a guessed master password is correct. Even when such a value is not the password itself, it can give an attacker a target for offline guessing after a breach. It can also turn the service into a required participant in local unlock.

NT² therefore keeps the ingredients used to verify and derive local access on the device. Your master password is not a cloud credential. It is not sent to the server, and the server does not keep the local salt or password verifier used by the vault. A network outage should not prevent you from opening data already on your device.

Email creates a related problem. It is useful for receipts or support communication, but it is a poor root identity for an encrypted vault. Email accounts can be reassigned, compromised, typoed, or controlled by another provider. If "who owns this email inbox?" becomes equivalent to "who owns this vault?", then email recovery can silently become vault recovery. That is a much stronger power than a billing address should have.

Design part one: unlock happens here

Local unlock starts with the master password you enter on your device. NT² uses PBKDF2 with SHA-256 and 100,000 iterations to derive an AES-256-GCM vault key. PBKDF2 deliberately makes each password guess cost more computation than a fast hash would.

The salt used in that process is unique to the vault and stored with the local vault metadata. It does not need to be secret; its job is to ensure that the same password used for two vaults does not produce the same derived key. What matters for the trust boundary is where the derivation happens and where its inputs go: the browser or app performs the work, and the master password never needs to leave it.

The vault also keeps a local password verifier. Conceptually, this is known data protected by the derived key. If the password is wrong, the device derives the wrong key and cannot successfully open the verifier. If it succeeds, the same key can be used to unwrap the keys that protect vault items.

This check remains local. There is no request that asks a server, "Was this the right master password?" The result is not a cloud session. It is an in-memory cryptographic capability on the current device.

That distinction also explains why the key is temporary. The derived key is created as a non-extractable browser CryptoKey and held only in memory while the vault is unlocked. Locking the vault, refreshing the page, closing it, or reaching the inactivity timeout clears that usable key. The encrypted files may remain on disk, but the ability to interpret them does not.

Local unlock can therefore succeed with no network connection and no cloud subscription. It proves nothing to an NT² server. It simply gives this running app the local capability to decrypt this vault.

Design part two: the vault proves itself

Optional cloud features need a different kind of proof. A synchronization service must reject strangers trying to read or write another vault's encrypted replicas. Yet asking for the master password would cross the boundary we just established.

Instead, the vault has a cryptographic identity built from a signing key. We call its public identifier a Vault Key DID. The name can sound more complicated than the operation, so consider a simple challenge–response exchange.

When the vault wants to authenticate, the server sends a fresh, unpredictable challenge: effectively, "Sign this one-time message so I know you are present now." The device signs that challenge with the vault's private signing key. The server verifies the signature with the corresponding public key it already associates with that vault.

The private signing key does not need to be uploaded. A valid signature proves that the device currently controls it, while the fresh challenge prevents an old captured response from being replayed later.

The exchange looks like this:

1. The vault asks to begin cloud authentication.
2. The server returns a short-lived random challenge.
3. The device signs the challenge locally.
4. The server verifies the signature against the vault's public identity.
5. The server issues a limited cloud session for authorized transport operations.

No identity theory lecture is required to understand the boundary. It is the digital equivalent of proving you possess a particular seal by stamping a new, one-use card. The verifier can recognize the seal without receiving the tool that makes it.

This cloud session can authorize operations such as uploading or retrieving encrypted replica data. It does not reveal the master password, derive the vault key, or decrypt the contents. The cloud recognizes a vault-shaped cryptographic identity, not an email inbox and not a human-readable display name.

The local display name is for the person using the device. An optional billing email is for receipts. Neither is the root of cloud authority. The signing key is what allows the vault to prove continuity to the service.

The trade-off: two mental models

This separation is not free. Users and developers now have two states to reason about:

• locked or unlocked locally, which describes access to decrypted vault contents;
• signed out or authenticated to the cloud, which describes permission to use optional remote services.

Those states can vary independently. A vault might be unlocked while the device is offline. It might be unlocked while cloud authentication has expired. A background sync process might have permission to move ciphertext without making the user interface capable of showing plaintext. A cloud account problem might interrupt synchronization while local search and editing continue.

A single "logged in" badge would be simpler, but it would be inaccurate. Good interface design should explain the two states without forcing people to learn cryptographic vocabulary. "Vault locked" and "Cloud sync needs attention" are clearer than one ambiguous authentication error.

The implementation also has more edges to handle. It must manage local key lifetime separately from cloud session lifetime. It must avoid accidentally sending a master password through an account form. It must ensure that reconnecting sync does not imply unlocking. Tests must cover combinations rather than one happy-path session.

We accept that complexity because it makes the threat boundaries visible. A server compromise threatens remote availability, account metadata, and encrypted replicas; it should not automatically produce the key that opens a local vault. A stolen unlocked device is a local security incident; it should not teach the server the master password. An email takeover may affect messages or billing, but it should not redefine vault ownership.

Clearer boundaries do not eliminate risk. They prevent unrelated powers from accumulating in one credential and one backend.

What we refuse to make equivalent

Two statements guide the design.

A cloud session is not a decrypted vault.

A server may accept a signature and authorize access to encrypted blobs. That says the requester controls the vault's signing identity. It does not mean the requester has entered the master password on this device, derived the local AES key, or opened any item. Authentication can grant transport rights without granting plaintext.

Email is not vault identity.

An email address may be useful at the edges of the product, but it does not become the cryptographic root of the vault. We do not want an inbox reset flow, support override, or identity-provider decision to substitute for the keys that define vault control.

These refusals close off some conventional conveniences. NT² cannot promise that a support agent can restore every secret after a forgotten master password. It should not pretend that signing into a website makes local ciphertext readable. The cost is a recovery model that asks users to care for backups and approved recovery methods.

The benefit is equally concrete: the cloud can help without becoming the locksmith.

Keep the boundary honest

Local-first architecture is not just a choice of storage API. It is a decision about authority. The device opens the vault because the device derives the key. The cloud serves optional features because the vault proves its identity with a signature. Neither operation needs to impersonate the other.

That gives us two mental models, but also two clean answers. Who can read the local data? Whoever can unlock it on the device. Who can use the optional cloud service for this vault? Whoever can answer a fresh challenge with its signing key.

When those answers stay separate, "login" stops being a hidden tunnel between your master password and a server account. It becomes two narrowly defined acts, each revealing only what its job requires.

For a wider view of why NT² keeps the device at the center, read why a PWA can be a local-first, zero-server vault.