An encrypted backup can look reassuring: its database is unreadable, its files are ciphertext, and the archive opens only through a recovery workflow. But unreadable does not necessarily mean intact. A damaged transfer can remove bytes. A sync conflict can mix generations. Malware can replace an archive. A malformed ZIP can add an unexpected member. If restore logic notices none of that until it replaces the working vault, confidentiality alone has not made recovery safe.
Quick answer
Yes—a current Krypt recovery backup or complete cloud-sync bundle can detect several important forms of corruption and tampering before it commits a restore. Krypt authenticates a canonical manifest with HMAC-SHA-256 using the vault master key. The manifest identifies the format, version, purpose, vault, recovery metadata, database, and encrypted file inventory. Restore requires the archive's member names to match that inventory exactly, then checks recorded byte lengths and SHA-256 digests and reconciles encrypted files with records in the SQLCipher database.
Verification is only the first boundary. Krypt extracts into a temporary area, prepares a separate staged database and file generation, verifies the staged copy, and uses a durable restore journal while replacing live data. If an operation fails before the new generation becomes durable, the coordinator attempts to restore the old generation. These controls detect many altered, incomplete, mismatched, and interrupted restores; they do not stop someone from deleting every copy, stealing ciphertext for offline attack, or replacing a backup and the trusted software or key used to verify it.
Confidentiality, integrity, and authenticity answer different questions
Backup security is easier to reason about when three properties stay separate. Confidentiality asks whether an unauthorized person can read the data. Integrity asks whether the bytes and structure remain as expected. Authenticity asks whether a party holding the appropriate secret authenticated the protected description. Availability is a fourth concern: can the owner still retrieve a usable copy when it matters?
| Control | Useful evidence | Important limit |
|---|---|---|
| Encryption | Content is not readable without the key | Does not by itself describe the complete expected archive |
| SHA-256 digest | Current bytes match a known digest | An unkeyed digest can be replaced with the altered file |
| HMAC-SHA-256 | Manifest and tag agree under a secret key | A party with the key can create a valid tag; it is not a public signature |
| Exact inventory | No listed member is missing and no unlisted member is accepted | The inventory must itself be authenticated |
| Tested restore | The recovery path works with the retained key and software | One successful test does not guarantee future availability |
NIST's June 2026 SP 1339 OT Backup Quick Start Guide is written for operational technology, but its lifecycle lesson is broadly useful: effective backup management includes regular creation, testing, and review during recovery exercises. The NCCoE's data-integrity recovery project likewise frames trustworthy recovery around data that is accurate and complete, not merely present.
Why an encrypted archive can still be wrong
Consider an archive containing a SQLCipher database and several encrypted photos. Every member may remain unreadable to an attacker, yet the archive can still fail as a recovery object. One photo may be missing. A database from Vault A may be paired with file blobs from Vault B. A stale manifest may describe an older generation. A transfer may be truncated after the central directory was written. An extra archive member may exploit overly permissive extraction logic. A valid backup may simply be used in the wrong restore flow.
Authenticated encryption on an individual file is valuable because a modified ciphertext normally fails verification when decrypted. It does not automatically prove that the collection contains every object referenced by a database, that the database is the expected one, or that nothing extra was inserted. Collection integrity needs an authenticated description of the collection and strict validation against it.
Checksums detect change only relative to a trusted expectation
NIST's Secure Hash Standard specifies SHA-256. Hashing a file produces a fixed-length digest that changes when the file changes with overwhelming probability. That makes a published checksum excellent for catching transmission errors or comparing a destination with an expected value retained elsewhere.
A checksum is not automatically an authenticator. If an attacker can replace backup.zip and the nearby text file containing its SHA-256 value, the attacker can hash the replacement and publish a consistent pair. The verifier sees agreement but has no secret or independently trusted reference tying the digest to the original backup.
That distinction separates Krypt's readable portability export from its recovery backup. The export article describes checksums.sha256 so an owner can independently detect later changes when the expected checksum is preserved through a trusted path. A recovery archive instead needs to bind an internal inventory to a secret available during recovery. The two artifacts solve different problems and should not be described interchangeably.
How HMAC-SHA-256 authenticates the manifest
A hash-based message authentication code combines a hash construction with a secret key. NIST FIPS 198-1 defines HMAC as a mechanism for message authentication using a cryptographic hash function and shared secret. The original construction is also specified in IETF RFC 2104.
Krypt serializes the unsigned manifest in a deterministic, canonical JSON form, prefixes a Krypt-specific domain string, and calculates HMAC-SHA-256 with the vault master key. On restore, it removes the integrity field, recomputes the HMAC over the same canonical representation, and compares the supplied and expected tags without exiting early on the first differing byte.
The domain string matters because it separates this use of the key from another protocol that might authenticate different data. Canonical serialization matters because semantically identical JSON can otherwise have different key ordering or whitespace. The HMAC covers recovery metadata as well as the file descriptions, so an attacker cannot silently swap the key-wrapping information while leaving file digests unchanged.
This is symmetric authentication, not a digital signature or proof of authorship to outsiders. It establishes that the manifest is consistent with possession of the relevant vault key. Anyone who acquires that master key can compute a new valid tag. Conversely, losing the Rescue Key can make an intact recovery archive unusable because Krypt cannot recover and use the master key needed to authenticate and open it.
What Krypt binds into a current backup
The current authenticated manifest declares a format name and version, a creation time, one of two allowed purposes—recovery_backup or complete_cloud_sync—and the vault identity. Restore supplies the expected purpose and vault, so a complete-sync bundle is not silently accepted as a recovery-backup archive, and a manifest naming another vault is rejected.
The database entry has the fixed member name vault.db, its SHA-256 digest, and exact byte length. Each encrypted file entry carries a stable sync identity, its files/... member name, stored encrypted-file format version, SHA-256 digest, and byte length. The authenticated recovery envelope is included as well.
During validation, Krypt constructs the complete allowed member set from manifest.json, vault.db, and every listed encrypted file. The extracted names must match that set exactly. Missing, renamed, duplicate, unsafe, and unexpected member names fail validation. The database is then opened with the recovered vault key and its file records are compared with the manifest: the number of records, stable identities, and expected stored names must agree. The database and file bytes must match their recorded lengths and SHA-256 digests.
For current KXF2 encrypted files, Krypt also checks that the header's bound vault identity, storage identifier, and object type match the database record. The recorded file-format version must match what Krypt detects. This prevents the archive from treating a correctly hashed but contextually mismatched current encrypted object as the file the database describes. Older encrypted member formats can be inventoried, but they do not gain KXF2's identity binding retroactively.
Krypt's answer: authenticate, stage, verify, then commit
Krypt is a zero-knowledge password manager designed so recovery does not require a server to learn the vault key. For a current recovery ZIP, the app first extracts into a temporary restore directory, obtains the candidate vault key through the recovery envelope and Rescue Key, and authenticates the manifest before installing the archive as live state. Complete cloud-sync bundles use the same authenticated archive manifest with the distinct complete-sync purpose.
A valid manifest does not trigger an in-place overwrite. Krypt copies the candidate database and encrypted files into operation-specific staging paths. For a recovery ZIP, Krypt opens the staged SQLCipher database and reconciles its files table with the authenticated archive inventory. Complete cloud-sync restores additionally run SQLCipher and SQLite integrity checks and require core Krypt tables. The coordinator fingerprints and verifies both staged and installed generations.
The restore journal records phases and fingerprints durably. Before installation, Krypt captures the old database generation and moves aside the old file generation. It then installs the staged database, files, and secure metadata, verifies the installed generation again, reopens application state, and only then marks the operation durable and removes old and staging artifacts.
If a normal error occurs before durability, the coordinator uses the recorded old inventory to roll back. If the process is interrupted, a remaining journal is examined during startup: a durable or finalizing operation is verified and finalized, while an earlier operation is rolled back. The journal does not make storage infallible, but it avoids treating a multi-file replacement as one indivisible action when the operating system can interrupt between steps.
Failure should stop the restore, not downgrade the checks
Current Krypt restore paths fail closed when the archive is malformed or its evidence disagrees. A missing authenticated manifest, unsupported format or version, wrong purpose, wrong vault identity, invalid HMAC, altered length or digest, mismatched database inventory, unexpected member, or current encrypted-file identity mismatch causes rejection. The implementation does not silently accept a partially matching archive and does not fall back from a failed current HMAC to an unsigned interpretation.
Legacy backups need an explicit boundary
The safeguards above apply to Krypt's current signed recovery-backup archives and current complete cloud-sync bundles. Legacy unsigned recovery ZIPs are explicitly rejected with guidance to create a new backup from the original device. An older complete-bundle format is also rejected rather than migrated through a weaker complete restore.
Krypt has a limited, separately acknowledged migration path for certain legacy standalone cloud database backups. That flow requires legacy recovery proof and validates the selected encrypted database under separate rules. It is not equivalent to the current complete archive: a database-only artifact cannot authenticate a complete database-plus-file member inventory that it never contained. Owners with access to an older device should create and test a current backup instead of depending on compatibility behavior.
What authenticated restore cannot promise
Integrity verification does not create availability. Ransomware or account takeover can delete accessible backups, and storage failure can destroy the only copy. CISA's StopRansomware Guide recommends offline encrypted backups and regular testing of backup availability and integrity. Multiple generations, at least one isolated copy, and rehearsed access to the required recovery material remain important.
Nor does a valid HMAC declare a device clean. Malware running after unlock may access authorized plaintext or coerce the application. Verification cannot detect a logically unwanted record that was already present when a legitimate backup was created. It does not prove that the newest backup is the best recovery point, prevent ciphertext theft, or erase copies held elsewhere. A correct restore can also reintroduce stale passwords or authenticator secrets that should be rotated after an incident.
Backup verification checklist
- Create a fresh encrypted recovery backup after meaningful vault changes, then confirm that the operation completed.
- Keep the matching Rescue Key or Recovery Kit through a separate protected path; do not assume the archive contains everything needed without it.
- Retain multiple backup generations and at least one copy that is not continuously writable from the everyday device.
- Test restoration before an emergency, using a controlled target and the current Krypt release from an official source.
- Never rename or edit internal archive members. Copy the complete backup as one artifact.
- Treat a verification failure as evidence to stop. Preserve the damaged file for diagnosis and try another known-good generation.
- After restore, inspect critical records and representative encrypted files; structural verification cannot decide whether the stored content is operationally current.
- After suspected compromise, rotate exposed credentials and re-establish authenticators rather than assuming restoration removes an attacker's sessions.
For the operational creation and recovery sequence, use Krypt's Recovery Backup guide. A backup test should prove not only that a ZIP exists, but that the owner can select the intended vault, supply the right recovery material, pass authentication and integrity checks, and inspect the restored result.
FAQ
Does encryption automatically detect a tampered backup?
No. Encryption protects confidentiality, but a backup also needs authenticated integrity checks to detect substitution, truncation, added files, or altered metadata. An authenticated-encryption format can protect individual encrypted objects, while a keyed manifest can bind the complete backup inventory and its intended restore context.
Why is a SHA-256 checksum not enough to authenticate a backup?
A SHA-256 checksum can detect an accidental change only when the expected checksum reaches you through a trusted path. An attacker who can replace both a backup and its unkeyed checksum can make the altered pair agree. HMAC-SHA-256 adds a secret key, so someone without the vault key cannot create a valid tag for a changed manifest.
What does Krypt do when backup verification fails?
Krypt rejects the restore when the current archive format, purpose, vault identity, HMAC, exact member set, byte lengths, SHA-256 digests, database inventory, or supported encrypted-file identity checks do not agree. Installation occurs through staged, journaled replacement; a failure before durability triggers rollback, and an interrupted operation is recovered from its journal at startup.
Can Krypt restore every backup created by an older version?
No. Current signed recovery backups and complete cloud-sync bundles use the authenticated archive safeguards described here. Legacy unsigned recovery archives and older complete bundles are rejected. A limited migration path exists for certain legacy standalone cloud database backups, but it is separately gated and does not provide the same complete-member guarantees. Create and test a current backup before retiring the original device.
Technical references
NIST SP 1339 addresses regular backup creation, testing, and recovery exercises. The NCCoE Data Integrity recovery project focuses on restoring data that is accurate and complete. The CISA StopRansomware Guide covers isolated, encrypted, tested backups. NIST FIPS 198-1 and RFC 2104 specify HMAC, while NIST FIPS 180-4 specifies SHA-256.
Use Krypt to create an encrypted recovery backup whose current archive inventory is authenticated before a staged, journaled restore.
