Why Senvra can change a password without re-encrypting every file

The short answer is: Senvra does not use your typed password as the direct encryption key for every photo, video, file, or note.

When a private space is created, Senvra creates a random space master key first. Your password and your Space Access Key are two separate ways to open that master key. The protected content remains under the space and item key system, so changing the password can replace the password wrapper without rewriting every encrypted file.

If you are evaluating Senvra, the important part is not just that encryption exists. It is how the keys are separated, what changes when a password changes, and where the recovery boundary sits. You can also read the Senvra product guide for the broader local-first model.

The password is not the file key

A simple photo locker could take a user password and use it too directly. That would be fragile. Human passwords are memorable, which means they usually have much less entropy than a random cryptographic key.

Senvra uses a different shape:

1. A private space receives its own random 256-bit master key.
2. The password is combined with a per-space salt and stretched with PBKDF2-HMAC-SHA256. Current production parameters use 600,000 iterations.
3. The derived password key opens an encrypted wrapper around the master key.
4. After unlock, the master key gives Senvra access to the encrypted space material and item-key system.

That distinction matters. The password is an authority for opening the space key. It is not the long-term file key copied into every encrypted object.

flowchart LR
    P[Typed password] --> KDF[PBKDF2-HMAC-SHA256 + space salt]
    AK[Space Access Key] --> HKDF[HKDF-SHA256 + access-key salt]
    KDF --> PW[Password wrapper]
    HKDF --> RW[Recovery wrapper]
    PW --> MK[256-bit space master key]
    RW --> MK
    MK --> IK[Item keys and encrypted space state]
    IK --> DATA[AES-256-GCM protected media, metadata, and thumbnails]

What the Space Access Key does

The Space Access Key is not a password hint. It is independent random recovery material generated for that private space. In Senvra, it is shown as grouped hexadecimal text so the user can store it somewhere separate from the phone.

Internally, the Space Access Key follows a separate derivation path from the password. It can open another encrypted wrapper around the same master key. That gives the user a recovery route without requiring Senvra to run a server-side password reset system or hold the key on the user's behalf.

This is also why the Access Key can help reset a forgotten password. If the Access Key is valid, Senvra can open the space master key through the recovery wrapper, then create a fresh password wrapper for the new password.

What actually protects the content

The space master key defines the boundary of the private space. Individual protected items use encrypted key material beneath that boundary. Large media files are split into bounded chunks, and chunks are sealed with AES-256-GCM authenticated encryption. Metadata and thumbnails are also protected rather than left as plain side data.

Authenticated encryption is important because privacy is not only about hiding bytes. The app also needs to reject tampering, truncation, reordered chunks, or encrypted material being moved into the wrong context. Senvra binds protected data to its intended space, item, metadata role, or chunk order so that these checks have a concrete boundary.

Why password changes are fast

When you change a private-space password, Senvra first verifies that the current authority can open the existing master key. Then it derives a new password wrapping key from the new password and a fresh salt. Finally, it seals the same master key under the new password wrapper and commits the updated credential descriptor.

The encrypted media files do not need to be decrypted and written again because their underlying space and item keys have not changed. The wrapper changed. The content encryption layer did not need to rotate just because the human password changed.

This is the same practical reason many well-designed encrypted systems use key wrapping. Human credentials can rotate without forcing a full rewrite of every large object.

What this does not claim

This design makes password rotation practical and keeps recovery under user control, but it is not a claim that any app can be absolutely secure in every situation.

If the device or operating system is compromised, if someone observes the password while content is unlocked, if the user exports a file to another app, or if both the password and Space Access Key are lost, those cases fall outside a simple promise of encryption. Senvra does not keep a server-side recovery backdoor for private spaces.

The intended promise is narrower and more verifiable: private content is processed locally, protected with independent keys and authenticated encryption, and recoverable only through credentials the user controls.