The Day a Backup Has to Work: How Senvra Brings Private Data Back

The day you truly need a backup is rarely a good day.

Maybe the phone is gone. Maybe the app was deleted by mistake. Maybe the device no longer turns on. At that point, the green checkmark you once saw in Settings means very little. Two things matter: whether the file in your hand can still be verified, and whether it can actually bring your data back.

That is why backup deserves its own explanation. For private data, “a backup exists” is not enough. It has to remain confidential after leaving Senvra, detect damage instead of silently accepting it, and let you test recovery before an emergency.

We reduced recovery to two things

After creating a Senvra backup, you need to keep:

1. the encrypted .senvrabackup file;
2. the Backup Key generated specifically for that file.

There is no additional Backup Password, and recovery does not depend on remembering the password that opened the original space.

The Backup Key is not a UUID or a string assembled from the time, device model, or space information. It comes from the system secure random-number generator and contains 20 random bytes: 160 bits of entropy. Senvra displays it as five groups of eight hexadecimal characters only to make reading and checking it easier.

Every new backup gets a new Backup Key. That key has one job and belongs to one backup.

flowchart LR
    V[Current space] --> B[Create new backup]
    B --> F[Encrypted file<br/>.senvrabackup]
    B --> K[Independent Backup Key<br/>160 bits of random entropy]
    F --> R[Recovery]
    K --> R

This is not two-factor backup protection, and we do not describe it as such. It is one strong, unpredictable cryptographic secret. The boundary is straightforward: the file alone cannot be opened; the key alone contains no data; if someone obtains both, the backup may be opened.

The important habit is therefore not inventing one more password. It is storing the file and the key separately.

Why we removed the Backup Password

Our first instinct was the obvious one: require a Backup Key and a Backup Password. Another field looks like another layer of security.

But backup has a different failure mode from everyday sign-in. A login can often be retried or reset. An offline backup cannot ask a server to help when one of its secrets has been forgotten years later. Every additional secret is another way to make the only surviving copy permanently useless.

More importantly, a randomly generated 160-bit Backup Key is not a human password. It has no dictionary words, birthdays, or keyboard patterns, and it does not rely on a person's ability to design a good password. An attacker faces a random space of 2^160, not a familiar short-password guessing problem.

So we made a deliberate tradeoff: instead of adding a human password for the appearance of complexity, we use one strong random key per backup and leave recovery with one secret that must not be lost or disclosed.

That makes the workflow lighter, but it does not reduce the user's responsibility. Senvra keeps no recoverable copy of the Backup Key. The app asks you to confirm that you saved it before backup creation continues. If the key is lost, Senvra cannot open that file either.

The Space Access Key and Backup Key open different doors

This distinction is easy to miss and important to understand.

An already-open private space should not give anyone holding the phone permission to export everything. Before creating a private-space backup, Senvra asks for the original Space Access Key and verifies locally that it belongs to the current space.

The setup screen also generates a separate Backup Key for this operation, but no backup file is created until the ownership check passes.

After approval, the Space Access Key has finished its job. It does not encrypt the backup, is not written into the file, and is not required for recovery. The independently generated Backup Key protects the file itself.

flowchart TB
    A[Space Access Key] --> O[Verify ownership locally]
    K[Generate independent Backup Key] --> C[Prepare backup credential]
    O -->|Accepted| E[Allow encrypted file creation]
    C --> E
    E --> R[Verify or recover later<br/>with Backup Key only]
    A -. Not stored in the file<br/>not used for file encryption .-> E

The separation has practical consequences:

• even while the iPhone and private space are open, a full export still requires the correct Space Access Key;
• leaking a Backup Key does not turn it into a credential that opens the live private space or resets its password;
• rotating a Space Access Key later does not invalidate backups that were already stored correctly.

The Everyday space has no ownership recheck, but every backup still receives its own independent Backup Key.

How the Backup Key protects the file

Senvra parses the Backup Key into its original 20 random bytes. HKDF-SHA256 combines that material with a fresh 32-byte salt stored in this backup and derives a 256-bit wrapping key.

Senvra also generates a new random 256-bit Archive Key. The Archive Key encrypts the actual content. The Backup Key-derived wrapping key authenticates a key check and wraps the Archive Key.

This does not turn 160 bits into a marketing claim of 256-bit credential strength. The strength of the credential remains bounded by the original 160 bits of random entropy. The hierarchy exists so that the user credential, archive key, and content encryption each have one clear responsibility, with fresh random context for every backup.

Inside the file, Senvra uses AES-256-GCM authenticated encryption. The manifest, item metadata, thumbnails, collections, tags, and content all remain inside the encrypted layer. The outer header contains only what a reader needs to identify and safely parse the file, such as format versions, creation time, a random container ID, the random salt, and feature flags.

A storage provider can still see that a file exists, its approximate size, and its .senvrabackup extension. Content encryption can protect what is inside; it cannot pretend the surrounding filesystem never saw a file.

A large video never becomes a plaintext ZIP first

We do not want backup creation to leave a plaintext ZIP waiting to be encrypted later.

Senvra reads each item through a bounded memory buffer, divides it into 4 MiB data frames, and seals each frame immediately with the random Archive Key. A large video does not need to exist as a complete plaintext backup in a temporary folder.

Every encrypted frame is bound to the format version, container ID, authenticated header context, frame sequence number, and frame type. On reading, Senvra also checks each item's byte count, chunk count, and SHA-256 content digest, followed by the archive's total item count, total bytes, and manifest digest.

Changing a chunk, reordering frames, truncating the file, substituting a frame type, or appending unexpected data makes verification fail.

A progress bar at 100 percent is not the end

This is one of the parts of the design we care about most.

Senvra first writes into a file-protected pending file. When encryption finishes, the app does not immediately hand that file to the user. It reads the entire container back, authenticates every encrypted frame, and confirms that the decoded manifest is exactly the one it intended to write. Only then is the pending file atomically published as a completed backup.

You then save it through Files or another destination. That copy can fail too, so Senvra compares the verified in-app file and the external copy by header, byte count, and complete-file SHA-256. Security Center records it as the current backup only after the two files match.

sequenceDiagram
    participant D as Current data
    participant P as Pending ciphertext
    participant F as User-saved file
    participant S as Security Center

    D->>P: Read and encrypt frame by frame
    P->>P: Read back and authenticate everything
    P->>F: User saves the external copy
    F->>S: Compare header, size, and complete-file digest
    S-->>D: Record as current only after a match

“A file was created” and “a safe copy was saved” are two different states. We do not want one green checkmark to blur them together.

A recovery drill is more than opening the header

Many backups fail not because they were never created, but because nobody tried recovery until the worst possible moment.

Senvra can run a recovery drill without importing anything. It asks for the matching Backup Key, opens the wrapped Archive Key, authenticates the header, reads every frame, validates the manifest and relationships, checks all content digests and the archive-end marker, and rejects trailing data.

The encrypted manifest also carries a fingerprint of the source content. That lets Senvra distinguish:

• a cryptographically valid older backup that can still be opened;
• a valid backup that also matches the current contents of this space.

Both may be useful, but they are not the same state. Only the second counts as a current recovery drill for the space.

Recovery adds trusted content; it does not replace the space

Senvra recovery is closer to “bring trusted content into this space” than “roll the phone back to a snapshot.”

A backup can be imported only into a current space of the same type. Recovery does not reconstruct a list of source spaces or reveal how many private spaces existed. It does not replace the current space's name, skin, password, Space Access Key, Face ID, or gesture settings.

Before writing an item, Senvra verifies the complete backup. Each item then enters its own file-protected pending directory, is encrypted again with a fresh item key belonging to the current space, read back for validation, and atomically published.

If import is interrupted, existing content remains intact. Choosing the same backup again lets Senvra recognize completed source items and skip them instead of making another copy.

The clipboard gets only a short visit

To make saving long keys practical, Senvra can temporarily copy a Space Access Key or Backup Key. The copy is marked local-only, so it is not offered to Universal Clipboard, and receives a fixed 120-second expiration.

If you copy something else during those two minutes, Senvra does not blindly erase the newer content. It actively clears the clipboard only when it still contains the key from that copy operation.

This does not turn the clipboard into a vault. It simply reduces exposure time. When saving a key, avoid third-party tools that upload clipboard or keyboard content.

A backup routine that works in real life

The practical version is simple:

1. Save the Backup Key in a trusted location before confirming backup creation.
2. Do not put the key in the filename or store it beside the .senvrabackup file in the same chat message, email, or unencrypted folder.
3. Keep at least two verified backup files in independent locations.
4. Create a new backup after meaningful content changes and let Senvra finish external-copy confirmation.
5. Run recovery drills periodically. Do not delete the last known-good backup until the new one has passed verification.

Senvra itself needs no network access and does not upload the backup for you. A location selected through Files may be synchronized under another provider's rules.

The optional Apple Recovery Copy is still an encrypted container that requires its Backup Key. Senvra can verify that copy and make it eligible for the system backup path, but it cannot promise that an Apple device backup exists, how long it will be retained, or that the system restore will always succeed.

Finally, the honest boundary

If you have the backup file but lose the Backup Key, Senvra cannot recover it for you.

If you have the Backup Key but lose every copy of the file, there is no data to restore.

If both are exposed together, the backup loses its confidentiality. This design does not pretend to solve careless storage, a jailbroken device, or an operating system already under someone else's control.

What we can do is make every stage an engineering fact that can be checked: prove ownership again before exporting a private space; generate an independent random key for every backup; avoid plaintext staging; authenticate every frame; read the result back; verify the external copy; and let recovery be rehearsed before it is needed.

That means more to us than a settings label saying “Your backup is encrypted.”

For the wider picture, read how Senvra protects private data on iPhone and the Senvra product guide.

Further reading

• RFC 5869: HKDF
• NIST SP 800-38D: GCM authenticated encryption
• Apple Platform Security
• OWASP MASVS-STORAGE-1