Zyra.ENPT
Zyra Vault
In development

Encrypted files.
A Windows drive.

Zyra Vault
WORKFLOW ILLUSTRATION
.zv
Project.zv

Fixed-size encrypted container

Password requiredUnlocked with a passwordMounted as V:
Windows drive V:Mounted
V:\Your files, through familiar apps
DocumentsFolder
ProjectsFolder
Notes.txtText document
Unlock the container first.Ready to mount as a drive.
Dismount when your work is finished.
01 / Keep files in an encrypted container. Password-based access starts the workflow.02 / Unlock the container with your password before mounting the volume.03 / Mount a Windows drive letter and work with files through your usual applications.
Illustrative workflow. Example names. No encryption or mounting happens in this browser.

A familiar Windows drive. A considered architecture beneath it. Explore the technologies implemented in the current development candidate.

Explore the architecture

YOUR FILES. YOUR WORKFLOW.

A container.
A drive. Your files.

Create a fixed-size encrypted .zv container. Unlock it with your password and mount it as a Windows drive letter. Work through familiar applications, then dismount when finished. Designed for Windows 10 and 11 on x64.

Zyra Vault native design reference with mounted drives
Native product design reference. Appearance may evolve during development.

BENEATH THE INTERFACE

Separate layers.
Defined responsibilities.

Encryption, authentication and trusted state solve different problems. The native format keeps their roles explicit, from the first password-derived key to each mounted write.

Your passwordArgon2id
Unlock materialAuthenticated header
Random volume seedHKDF-SHA-256
DataMetadataIntentAuthentication
Conceptual key flow. Profile-specific effective keys are handed to the driver; password and header material remain in user mode.
01

Password → unlock material

Argon2id v1.3

A memory-hard password derivation step. Three KDF choices use 64 MiB, 256 MiB or 1 GiB of memory, with three passes and one lane. These are password-derivation settings, separate from the Fast and Authenticated storage profiles.

Implementation details

Creation requires at least 12 Unicode scalar values and allows at most 1,024 UTF-8 bytes. Passwords matching the embedded offline common-password list are rejected. A longer passphrase is recommended. Original password bytes enter Argon2id unchanged.

02

One purpose per key

Randomness + HKDF-SHA-256

Each new vault has an independent random salt, vault identifier and volume-key seed. HKDF derives separate keys for header, data, metadata, write intent and authentication. Password-derived unlock material and volume keys have distinct roles.

Implementation details

The authenticated bootstrap and header are checked before protected fields are accepted. Comparisons use constant-time routines. Passwords, KDF inputs and header key material remain in user mode; the driver receives applicable effective keys only.

03

Confidentiality at rest

AES-256-XTS · Serpent-256-XTS

AES-256-XTS is the default native cipher; Serpent-256-XTS is an alternative. Independent data and tweak keys operate on 512-byte data units. XTS provides encryption; it does not authenticate file data by itself.

Implementation details

The Windows CNG AES-XTS path is selected only after known-answer and byte-parity checks. A shared portable implementation supports the same format. Acceleration does not change the format or add a security guarantee.

04

Verify before plaintext

HMAC-SHA-256 · 4 KiB

In the Authenticated profile, each materialized 4 KiB data unit has an HMAC bound to the vault, profile, logical unit and version. The tag is verified before decryption and before plaintext is released.

Implementation details

Encrypted metadata conceals tags, maps and versions. SHA-256 digests connect ciphertext pages through a tree to a root protected by an HMAC anchor. Hashes alone are not treated as authentication.

05

A deliberate commit boundary

Protected intent · two barriers

For a durable commit, Authenticated first persists a bounded, protected intent. A real storage barrier precedes the data, metadata and anchor update. A second barrier precedes publication of the new root.

Implementation details

Interrupted state is classified as all-old, all-new, mixed or neither. Mixed and ambiguous state is blocked. This detects inconsistent state; it is not a complete undo/redo journal or a promise of automatic repair.

06

Remember the trusted state

Host-local rollback / fork detection

The Authenticated profile keeps a trusted generation and root digest on the host. An older generation signals rollback; a different root at the same generation signals a fork.

Implementation details

Ledger records use HMAC-SHA-256, a host secret protected by DPAPI-NG, restrictive ACLs and reparse checks. This authority is local to that host. Opening on a new host needs an explicit trust or reset decision.

07

Constrain the runtime

Isolated worker · authenticated IPC

A restricted Low Privilege AppContainer handles container parsing and password derivation apart from the privileged broker. Image, token and session checks, child restrictions and a kill-on-close job bound that worker.

Implementation details

IPC has bounded schemas and caller authentication. Drive visibility and ACLs follow the caller logon. The broker retains the authorized file object; writable mounts require an exclusive lease and qualified storage semantics.

08

Keep secret lifetimes narrow

Page locking · secure erasure

Password and IPC owners use mutable, pinned, page-locked buffers with bounded lifetimes and wiping before release. Scoped, move-only owners manage keys. The Argon2 workspace is wiped but is not page-locked.

Implementation details

Unlock work has memory and concurrency limits, deadlines and in-memory failure throttling. Diagnostics exclude passwords, keys and plaintext from their contract. These measures do not stop guesses made offline or guarantee safety on a compromised host.

CHOSEN AT CREATION

Two profiles.
A meaningful distinction.

Both profiles authenticate the bootstrap and header. File-data authentication and host-local state protection belong to Authenticated. The profile is fixed when the container is created.

FAST

Direct encrypted storage.

A lighter data path with AES-XTS or Serpent-XTS. File data is encrypted, but is not authenticated. No Authenticated metadata tree or host rollback ledger.

AUTHENTICATED

Verification alongside encryption.

Adds per-unit HMAC verification, encrypted authenticated metadata, ordered durable commits and host-local rollback/fork detection. Ambiguous interrupted state is blocked.

B1 and B2 are real storage barriers. Detection of inconsistent state is distinct from automatic recovery.

THE DEVELOPMENT BOUNDARY

Clear about what
comes with the design.

The current native implementation is a development candidate. Implementation presence is separate from installed-runtime qualification, public release and independent security review.

Bounded compatibility

The legacy reader covers ordinary TrueCrypt AES-XTS file containers, password-only and read-only. Legacy header PRFs are not native Zyra password settings. Disk, system and hidden volumes are outside the current scope.

Still being qualified

Linux/macOS interoperability, physical power-loss validation, Microsoft-accepted signing and Secure Boot remain separate, unverified work. There is no announced independent audit or certification. Host compromise and reliable backups remain relevant to how any encrypted storage is used.

Technical description reviewed against native-format, native-format-freeze, authenticated-runtime and development specifications on 7 October 2026.

In development

Zyra Vault and Zyra REC are in active development. Public availability, pricing and release dates have not been announced.

ONE FAMILY. TWO PURPOSES.

Discover the other productZyra REC