Quantum Vault

External copies may still exist

This warning is monotonic for the current page lifetime: clearing page memory, cancelling, changing workflows, or switching modes cannot prove that a browser-managed download or pending object URL was deleted.

Create Archive

Select files once, and Quantum Vault will encrypt them and export successor shards plus archive JSON.

📄 File

→

🔒 Encrypt

→

🧩 Split

Select files to protect

Drag files here or use the file picker to select plaintext inputs for local encryption. Lite accepts 1–256 files and at most 8 MiB aggregate per operation.

🛡️ Fresh keys are generated per archive

I explicitly authorize retaining and exporting the raw ML-KEM private key for this archive. This creates a unilateral 1-of-1 recovery root and bypasses the shard threshold. Default is threshold-only recovery. This acknowledgement resets after every create attempt and must be made separately for each archive. If authorized, export or explicitly discard the pending key before creating another archive or switching modes.

Total shards (n) ℹ

Approximate recovery threshold (%) ℹ

Requested 60% -> Achievable 80% (>=4/5 shards) Discrete by RS/SSS constraints.

Archive authenticity policy Choose whether restore should require detached archive approval.

Technical context

Lite creates successor lifecycle archives by default and exports successor .qcont shards, a signable .archive-state.json, and a mutable .lifecycle-bundle.json. Without an external archive-approval signature over the archive-state descriptor, restore verifies integrity only and does not claim archive approval. Same-state resharing stays in Pro as an optional maintenance tool and does not replace archive approval while the archive state stays unchanged.

Verify required archive artifacts

Each Download or Retry click requests exactly one artifact. A row remains unverified until you re-import the exact bytes through the file picker. Re-import verification does not prove durable storage.

Until completion or cancellation, this page temporarily holds the operation key and a complete recovery set. Re-importing every shard exposes that recovery set to this browser session.

Custody and archive exports

Recovery depends on independent shard custody and exported JSON descriptors, not on keeping browser keys around.

Store QVqcont-7 shards across separate locations or custodians.
Retain the archive-state descriptor and lifecycle bundle JSON; Review, Pro Attach, and Restore depend on them.
Browser download requests are not storage confirmation. Lite completes only after every required planned artifact is exactly re-import verified; separately confirm durable, independent custody.
Archive approval happens outside the browser: sign archive-state bytes, then use Pro Attach for signatures and evidence.
Optional 1-of-1 Key Backup bypasses the shard threshold; skip it when custody policy forbids retaining a unilateral ML-KEM recovery key.

Last create export checklist

Every required artifact passed exact name, size, and SHA3-512 digest re-import verification. This is not durable-storage evidence; confirm independent custody separately.

Restore

The restore decision updates as you load shards and evidence; details and selection follow below.

🧩 Shards

→

✨ Combine

→

📄 File

Select Shards to Restore

Load successor .qcont shards and any detached signatures, signer keys, or timestamp proofs you want checked.

0 shards selected

Review loaded archive details

Artifacts

Lifecycle

Archive and state selection

Same-state cohort selection

Lifecycle bundle selection

Evidence

Detached signatures, signer pins, and OTS proofs are listed under Artifacts. Verification counts appear in Lite restore output after you run restore.

Technical

Technical context

Load successor .qcont shards plus any optional .archive-state.json, .lifecycle-bundle.json, detached signatures, .pqpk signer pins, and .ots proofs in the main selector above. A supplied .pqpk file counts as a pinned PQ signer key. Restore remains policy-gated and releases recovered outputs only after the selected archive policy is satisfied.

Signer pins (optional)

Expected Ed25519 signer (optional)

Workflow Create

Archive state No archive selected

Policy strong-pq-signature

Threshold not configured

Evidence not loaded

Create Archive

Generate or load keys, encrypt data, then split the encrypted container into successor shards and archive JSON.

Key Generation

Generate a new keypair in memory. Overwrites existing session.

Collecting entropy...

Heuristic collection progress only. This is not a measured cryptographic guarantee. The browser CSPRNG remains the baseline for key generation. Privacy-preserving, local-only capture of mouse/keyboard timing and window changes. Optional supplemental mixing — not required for secure keys.

Active Session

Private Key (.qkey) ℹ Select an ML-KEM private .qkey only for local decryption or split operations.

Public Key (.qkey) ℹ Select an ML-KEM public .qkey for encryption targets.

Encryption

Encrypt to .qenc with a loaded public key, or decrypt locally with a loaded private key.

File Operations

Input Files Select plaintext files to encrypt, or an encrypted container to decrypt when a private key is loaded.

Container strategy Pack files into one container One container per file

Load keys in Key Management: public key for encryption and private key for decryption.

Split Into Successor Shards

Load a .qenc and matching private key to export successor shards and archive JSON.

Split Configuration

Load the encrypted container and matching private key, then choose shard geometry and restore policy.

Encrypted container (.qenc) Select the encrypted container that will be converted into successor shards.

Private Key (.qkey) Select the 3168 B private .qkey needed to unwrap the encrypted container locally.

Shard geometry (n, k)

Total shards (n)

Data shards (k)

Params info...

n >= 5

2 <= k < n

(n - k) must be even

Data k Parity m Threshold t

Configuration Tips

More availability = reduce k or t;
More confidentiality = increase m.
If someone controls t shards they can decrypt; with fewer than t shards they cannot.
m — in the context of RS is the number of redundant parity shards.
t — in the context of SSS, this is the threshold: the minimum number of Shamir shards required to recover the secret.

Archive authenticity policy Choose whether restore should require detached archive approval.

Technical context

Split exports successor QVqcont-7 shards plus .archive-state.json, .cohort-binding.json, and .lifecycle-bundle.json. Without an external detached archive-approval signature over the archive-state descriptor, restore will block before the file is decrypted. Archive approval stays detached from shard creation: sign the exported .archive-state.json later, then use Attach to merge detached evidence into the lifecycle bundle without changing archive-state bytes.

Review Artifacts

Classify and inspect selected archive artifacts before maintenance or restore. Restore eligibility is evaluated only in Restore.

Artifact Intake

Review inputs

Load successor shards, archive-state descriptors, lifecycle bundles, detached signatures, signer pins, and timestamp evidence to inspect classification. This does not verify restore eligibility.

0 review files selected

Review loaded archive details

Artifacts

Lifecycle

Evidence

Review is an inspector. Restore remains the policy gate for plaintext release, and Attach remains the evidence merge workflow.

Maintain Evidence

Merge archive approval, maintenance, source evidence, signer pins, or OTS artifacts without changing archive-state bytes or archive-policy semantics.

Merge Lifecycle Evidence

Evidence channel

Archive approval attaches detached signatures over the canonical archive-state descriptor. Maintenance and source-evidence remain separate evidence channels and never satisfy archive policy on their own.

Attach inputs

Load one archive cohort plus any detached signatures, signer pins, timestamps, and channel-specific JSON artifacts you want to merge. Signing remains external.

Source-evidence builder for external signing

Relation type

Source object type

Source digests

What you are binding

Each digest is a cryptographic fingerprint of the exact byte contents of the source object you name in Source object type (for example the canonical *.archive-state.json file, not a display name or filesystem path). Use Apply one file to all rows when the same file should be hashed once per row algorithm (typical for one canonical artifact, multiple digest algorithms). You still choose relation type and source object type deliberately. Optional media type is never inferred from filenames.

External source-signature refs (optional)

Include optional media type Optional descriptive fields are not privacy-preserving. Keep them empty unless you intend to disclose that metadata.

Media type

Export the canonical JSON here, sign it with an external tool, then re-import that .json plus the detached signature through this Attach surface.

0 attach files selected

I understand only the selected shard files will be rewritten. The updated lifecycle bundle will still be exported. Any unselected shards from the same cohort may continue carrying older embedded lifecycle-bundle bytes.

Review loaded attach evidence

Artifacts

Lifecycle

Evidence

The Attach plan card states the operational target, policy role, and shard scope. Full binding references and digest lines are under Technical. A verification matrix appears in Attach result after a successful merge.

Technical

Technical context

Successor attach can update only the lifecycle bundle or also re-embed that bundle into the selected shard files, depending on what you load. Load successor .qcont shards, optional .archive-state.json or .lifecycle-bundle.json files, detached signatures, .pqpk signer pins, .ots proofs, and when needed a canonical .transition-record.json or .source-evidence.json artifact. Attach never changes the signable archive-state bytes. All signing remains external to this browser UI. This UI does not generate signing keys and it does not collapse maintenance or source-evidence into archive approval.

Signer pin (optional)

Expected Ed25519 signer (optional)

Evolve Successor Cohort

Rotate a successor cohort while preserving the archive-state approval target.

Emit a New Successor Cohort

Reshare inputs

Load one successor cohort and any explicit lifecycle bundle you want to use for disambiguation, then emit a new cohort.

0 shards selected

Review loaded reshare evidence

Artifacts

Lifecycle

Archive and state selection

Predecessor cohort selection

Lifecycle bundle selection

Evidence

The Reshare plan card summarizes counts by channel. Verification details appear after you emit a cohort.

Technical

Technical context

Same-state resharing is maintenance, not archive re-approval. It keeps the archive-state approval target unchanged and emits a new cohort plus a transition record. This tool emits maintenance artifacts only. It does not create legacy material and it does not run full archive-policy evaluation like Restore. An uploaded .lifecycle-bundle.json can explicitly choose one embedded lifecycle-bundle digest when needed.

Shard geometry (successor cohort)

Same RS/SSS rules as Split. These values define the new cohort you are emitting.

Total shards (n)

Data shards (k)

Params info...

n >= 5

2 <= k < n

(n - k) must be even

Data k Parity m Threshold t

Transition metadata

Record the maintenance context that will be written into the emitted transition record.

Transition reason

Operator role

Transition notes

Restore

Step 4: read the restore decision first, then load shards and evidence; recover when policy is satisfied.

Restore Archive

Restore inputs

Load shards and any detached verification artifacts you want checked before recovery.

0 shards selected

Review loaded archive details

Artifacts

Lifecycle

Archive and state selection

Same-state cohort selection

Lifecycle bundle selection

Evidence

Detached signatures, signer pins, and OTS proofs are classified under Artifacts. The verification matrix appears in Restore result after Evaluate Restore.

Technical

Technical context

Successor restore is the regular-user path. Load successor .qcont shards plus any optional .archive-state.json, .lifecycle-bundle.json, detached signatures, .pqpk signer pins, and .ots proofs in the main selector above. A supplied .pqpk file counts as a pinned PQ signer key. Restore remains policy-gated and detached archive approval stays separate from maintenance, source-evidence, and OTS reporting.

Signer pins (optional)

Expected Ed25519 signer (optional)