COMING SOON

SECURITY IS NOT A FEATURE. IT’S THE FOUNDATION.

Security architectureUnder the hood.

From the master password and key hierarchy to authenticated commits, crash recovery and end-to-end synchronization. Clearly explained, with explicit security boundaries.

Argon2idHKDF-SHA-256XChaCha20-Poly1305Rust CoreAuthenticated Commits
Contents ⌄
Visual explanationsTechnical reference

01 / VISUAL SECURITY LAB

Explore the architecture

Explore key derivation, encrypted records, storage transitions, synchronization and security boundaries through interactive diagrams. Each diagram links to its technical reference.

01

INTERACTIVE · SECURITY ENGINEERING

Security architecture

The Flutter UI handles interaction; a shared Rust security core enforces cryptographic operations, state transitions and input validation. Platform adapters and storage transports operate behind defined trust boundaries.
In simple terms

The Flutter UI handles interaction; a shared Rust security core enforces cryptographic operations, state transitions and input validation. Platform adapters and storage transports operate behind defined trust boundaries.

Security boundary

A compromised authorized client may expose plaintext during normal use.

Technical details

The Flutter UI handles interaction; a shared Rust security core enforces cryptographic operations, state transitions and input validation. Platform adapters and storage transports operate behind defined trust boundaries.

A compromised authorized client may expose plaintext during normal use.

Read chapter ↗
02

INTERACTIVE · SECURITY ENGINEERING

Master password + Secret Factor

Master password
Argon2id v1.3
Secret Factor (256 bits)
CSPRNG → 32 bytes
↓
HKDF-SHA-256
Unlock key → key envelope → LPRK
Only ciphertext is stolen. The separate Secret Factor is missing; guessing the password is insufficient.
In simple terms

A 256-bit random Secret Factor is independent of the master password. Argon2id output and the factor are combined through a versioned HKDF context. A local factor file has a defined VQYFACT1 header; sharing the vault’s access rights weakens isolation.

Security boundary

A locally stored Factor is not automatically independent MFA.

Technical details

A 256-bit random Secret Factor is independent of the master password. Argon2id output and the factor are combined through a versioned HKDF context. A local factor file has a defined VQYFACT1 header; sharing the vault’s access rights weakens isolation.

A locally stored Factor is not automatically independent MFA.

Read chapter ↗
03

INTERACTIVE · SECURITY ENGINEERING

Multi-level key hierarchy

Master password + Secret Factor (256 bits)
Unlock key → key envelope → LPRK
LPRK
Vault Epoch Key
Record DEK
Collection Keys
The unlock key opens a protected envelope containing an independently random Local Profile Root Key (LPRK). Vault Epoch Keys, wrapped per-revision DEKs and Collection Keys separate unlocking, data encryption and sharing.
In simple terms

The unlock key opens a protected envelope containing an independently random Local Profile Root Key (LPRK). Vault Epoch Keys, wrapped per-revision DEKs and Collection Keys separate unlocking, data encryption and sharing.

Security boundary

Lost unlock material may make recovery impossible.

Technical details

The unlock key opens a protected envelope containing an independently random Local Profile Root Key (LPRK). Vault Epoch Keys, wrapped per-revision DEKs and Collection Keys separate unlocking, data encryption and sharing.

Lost unlock material may make recovery impossible.

Read chapter ↗
04

INTERACTIVE · SECURITY ENGINEERING

Per-record encryption

Login ADEK A1Revision 1
Login BDEK B1Revision 1
Login CDEK C1Revision 1
Login DDEK D1Revision 1
Other records remain unchanged
In simple terms

Editing a record produces a new unique revision with a fresh random 256-bit DEK and bound metadata. Previously published encrypted revisions are not rewritten in place.

Security boundary

Old revisions may remain accessible under retention rules.

Technical details

Editing a record produces a new unique revision with a fresh random 256-bit DEK and bound metadata. Previously published encrypted revisions are not rewritten in place.

Old revisions may remain accessible under retention rules.

Read chapter ↗
05

INTERACTIVE · SECURITY ENGINEERING

Atomic writes & crash recovery

VALIDATEDEKENCRYPTWRITE TEMPFLUSHPUBLISH RECORDPUBLISH COMMITUPDATE HEAD
The previous commit remains authoritative. An incomplete temporary object is not a valid state.
In simple terms

The write sequence validates input, generates a revision and DEK, encrypts, writes and flushes objects, publishes them without replacing existing identifiers, creates and publishes a commit, then updates the local head.

Security boundary

Missing objects and failed hardware can defeat recovery.

Technical details

The write sequence validates input, generates a revision and DEK, encrypts, writes and flushes objects, publishes them without replacing existing identifiers, creates and publishes a commit, then updates the local head.

Missing objects and failed hardware can defeat recovery.

Read chapter ↗
06

INTERACTIVE · SECURITY ENGINEERING

Monolith vs. object store

Naive monolith (illustrative)
100 GB VAULT
Δ RECORD
Object storage
BLOBRECRECBLOBRECRECBLOBRECRECBLOBRECREC
Δ RECORD + INDEX + COMMIT
A small password edit inside a very large vault creates a new record, commit and needed index changes rather than automatically rewriting every object. Exact transferred bytes depend on the format and backend; other designs may support efficient deltas too.
In simple terms

A small password edit inside a very large vault creates a new record, commit and needed index changes rather than automatically rewriting every object. Exact transferred bytes depend on the format and backend; other designs may support efficient deltas too.

Security boundary

Other designs can also achieve efficiency through delta synchronization.

Technical details

A small password edit inside a very large vault creates a new record, commit and needed index changes rather than automatically rewriting every object. Exact transferred bytes depend on the format and backend; other designs may support efficient deltas too.

Other designs can also achieve efficiency through delta synchronization.

Read chapter ↗
07

INTERACTIVE · SECURITY ENGINEERING

Authenticated commit graph

Commit A
Commit B
Commit C · Device 1
Commit D · Device 2
Merge E
A malicious provider can withhold otherwise authentic commits.
In simple terms

Authenticated commits reference parent commits and the exact active encrypted objects. Concurrent writers can create multiple valid tips; a timestamp is not sufficient to pick a winner.

Security boundary

A malicious provider can withhold otherwise authentic commits.

Technical details

Authenticated commits reference parent commits and the exact active encrypted objects. Concurrent writers can create multiple valid tips; a timestamp is not sufficient to pick a winner.

A malicious provider can withhold otherwise authentic commits.

Read chapter ↗
08

INTERACTIVE · SECURITY ENGINEERING

End-to-end synchronization

Device A
⇆AEAD · CIPHERTEXT
Storage provider
⇆AEAD · CIPHERTEXT
Device B
Local changes work offline; upload can follow later.
In simple terms

Authorized clients encrypt locally and exchange encrypted objects and commit references. New data objects become available before the commit that references them. Offline edits and diverging histories are represented explicitly.

Security boundary

The provider can delete, delay or replay encrypted objects.

Technical details

Authorized clients encrypt locally and exchange encrypted objects and commit references. New data objects become available before the commit that references them. Offline edits and diverging histories are represented explicitly.

The provider can delete, delay or replay encrypted objects.

Read chapter ↗
09

INTERACTIVE · SECURITY ENGINEERING

Integrity is not freshness

Commit C1Authentic but oldAEAD ✓
←
Commit C2Confirmed newer commitAEAD ✓
AEAD validates an old authentic state but cannot prove freshness.
In simple terms

AEAD authenticates contents, not freshness. An older complete and valid vault can be replayed; reliable rollback detection requires an independently protected reference to an accepted newer state.

Security boundary

A complete rollback requires a separate trusted freshness anchor to detect reliably.

Technical details

AEAD authenticates contents, not freshness. An older complete and valid vault can be replayed; reliable rollback detection requires an independently protected reference to an accepted newer state.

A complete rollback requires a separate trusted freshness anchor to detect reliably.

Read chapter ↗
10

INTERACTIVE · SECURITY ENGINEERING

Business & Enterprise access

ROLE
PRIVATE
FINANCE
DEVELOPMENT
Owner
✓
✓
✓
Finance User
—
✓
—
Developer
—
—
✓
Collection access is governed by wrapped keys, not only server roles
In simple terms

Owner, Admin, Editor and Viewer permissions are separate from actual possession of decryption keys. Collection Keys and device-bound envelopes isolate datasets; revoked users cannot be made to forget plaintext already learned.

Security boundary

Plaintext already learned by a former member cannot be retroactively revoked.

Technical details

Owner, Admin, Editor and Viewer permissions are separate from actual possession of decryption keys. Collection Keys and device-bound envelopes isolate datasets; revoked users cannot be made to forget plaintext already learned.

Plaintext already learned by a former member cannot be retroactively revoked.

Read chapter ↗
11

INTERACTIVE · SECURITY ENGINEERING

Threat model

Select scenario

Vault theft

Technical details

Secret Factor + Argon2id + AEAD

Security boundary

Factor storage and password strength remain critical

In simple terms

Explicit scenarios include vault theft, factor theft, ciphertext tampering, cross-vault substitution, crash, full disk, malicious provider, conflicting writers, rollback and compromised clients. Each scenario has a mechanism and a residual boundary.

Security boundary

No single control mitigates every threat scenario.

Technical details

Explicit scenarios include vault theft, factor theft, ciphertext tampering, cross-vault substitution, crash, full disk, malicious provider, conflicting writers, rollback and compromised clients. Each scenario has a mechanism and a residual boundary.

No single control mitigates every threat scenario.

Read chapter ↗
12

INTERACTIVE · SECURITY ENGINEERING

Audit & evidence

01   Architecture02   Implementation03   Automated tests04   Platform validation05   Independent audit
The security behavior is documented; this alone does not prove implementation.
In simple terms

Independent review needs testable protocol contracts: KDF profiles, salt and nonce rules, AAD encoding, record and commit formats, error handling, filesystem persistence, multi-writer authorization, recovery and deployment-specific builds.

Security boundary

Security properties are examined through defined protocol contracts, implementation reviews, reproducible tests and platform-specific validation.

Technical details

Independent review needs testable protocol contracts: KDF profiles, salt and nonce rules, AAD encoding, record and commit formats, error handling, filesystem persistence, multi-writer authorization, recovery and deployment-specific builds.

Security properties are examined through defined protocol contracts, implementation reviews, reproducible tests and platform-specific validation.

Read chapter ↗

02 / TECHNICAL REFERENCE · V1.2

Technical reference

Technical chapters describe the key derivation, formats, threat assumptions, error handling and design choices. This language edition provides concise expert summaries with links to the complete German reference.

01Security is not a feature+

Verifiable security requires protection across the whole data lifecycle, not just an encryption algorithm. The model covers creation, use, synchronization, recovery and deletion, including failures and malicious storage behavior.

Full German reference ↗

02Six foundational security principles+

Confidentiality, integrity, consistency, recoverability, availability and user sovereignty are distinct objectives. An authenticated vault may still be stale; a consistent state may still become unavailable.

Full German reference ↗

03System architecture+

The Flutter UI handles interaction; a shared Rust security core enforces cryptographic operations, state transitions and input validation. Platform adapters and storage transports operate behind defined trust boundaries.

Full German reference ↗

04Cryptographic primitives+

Argon2id v1.3 (128 MiB, 3 iterations, 4 lanes, 256-bit output) hardens password derivation. HKDF-SHA-256 separates key purposes. XChaCha20-Poly1305 provides 256-bit keys, 192-bit nonces and 128-bit authentication tags.

Argon2id v1.3 · 128 MiB / 3 / 4 · HKDF-SHA-256 · XChaCha20-Poly1305

Full German reference ↗

05Master password and Secret Factor+

A 256-bit random Secret Factor is independent of the master password. Argon2id output and the factor are combined through a versioned HKDF context. A local factor file has a defined VQYFACT1 header; sharing the vault’s access rights weakens isolation.

VQYFACT1 · 32-byte CSPRNG secret · HKDF-SHA-256

Full German reference ↗

06Multi-level key hierarchy+

The unlock key opens a protected envelope containing an independently random Local Profile Root Key (LPRK). Vault Epoch Keys, wrapped per-revision DEKs and Collection Keys separate unlocking, data encryption and sharing.

Unlock → Envelope → LPRK → VEK → DEK

Full German reference ↗

07Authenticated associated data+

AEAD associated data binds format, profile, vault, key epoch, object, revision, entry type, schema version and deletion state. This prevents a valid ciphertext from being silently accepted in the wrong context; AAD itself is not secret.

AAD: vault_id | object_id | revision_id | epoch | version

Full German reference ↗

08One logical vault, many encrypted objects+

The logical vault comprises immutable record revisions, blobs, commits and head pointers. Head files are reconstructible hints rather than sole cryptographic authorities.

meta/ · commits/ · records/ · blobs/ · heads/

Full German reference ↗

09Immutable records and revisions+

Editing a record produces a new unique revision with a fresh random 256-bit DEK and bound metadata. Previously published encrypted revisions are not rewritten in place.

Full German reference ↗

10Authenticated commit graph+

Authenticated commits reference parent commits and the exact active encrypted objects. Concurrent writers can create multiple valid tips; a timestamp is not sufficient to pick a winner.

commit ID · vault ID · parent IDs · record refs

Full German reference ↗

11Complete write transaction+

The write sequence validates input, generates a revision and DEK, encrypts, writes and flushes objects, publishes them without replacing existing identifiers, creates and publishes a commit, then updates the local head.

VALIDATE → ENCRYPT → WRITE → FLUSH → PUBLISH RECORD → PUBLISH COMMIT → HEAD

Full German reference ↗

12Power loss, crash and recovery+

Crash recovery verifies complete referenced objects and commit ancestry. If exactly one fully valid tip is available, the head may be reconstructed. Ambiguous tips or damaged active objects require explicit error or conflict handling.

Full German reference ↗

13Running out of disk space+

Insufficient disk space can occur after a preflight check. Every write and flush result must be checked; an incomplete object must never be confirmed by a valid commit. Ambiguous publication status requires revalidation.

Full German reference ↗

14Filesystem safety and hardware limits+

File publication, fsync and path safety differ across NTFS, Linux, macOS and mobile platforms. Symlink, junction and TOCTOU attacks matter; software cannot guarantee the behavior of defective storage hardware.

Full German reference ↗

15Encrypted attachments and blob chunks+

Large attachments are split into independently encrypted chunks, e.g. up to 4 MiB of payload per chunk. Ciphertext hashes identify stored chunks; authentication binds sequence, size and object context. Plaintext-derived convergent keys are not used.

4 MiB chunk profile · SHA-256(ciphertext)

Full German reference ↗

16The 100 GB vault+

A small password edit inside a very large vault creates a new record, commit and needed index changes rather than automatically rewriting every object. Exact transferred bytes depend on the format and backend; other designs may support efficient deltas too.

Full German reference ↗

17Manifests, index shards and scaling+

Authenticated manifests can be partitioned into versioned index shards. Root-to-leaf references retain integrity while reducing the metadata region touched by small changes. Scaling claims must be measured, not invented.

Full German reference ↗

18End-to-end encrypted synchronization+

Authorized clients encrypt locally and exchange encrypted objects and commit references. New data objects become available before the commit that references them. Offline edits and diverging histories are represented explicitly.

Full German reference ↗

19SFTP, WebDAV and object storage+

SFTP, HTTPS/WebDAV and S3-like providers have different capabilities for conditional writes, atomic replacement, listing completeness and pagination. Backend-specific adapters must enforce real guarantees rather than assuming uniform semantics.

SFTP · WebDAV/HTTPS · S3-like

Full German reference ↗

20Conflicts and multiple devices+

Two devices can change the same item from a common ancestor. Both authenticated branches must be preserved until a controlled merge; last-writer-wins based solely on wall-clock time risks silent data loss.

Full German reference ↗

21Rollback protection and freshness+

AEAD authenticates contents, not freshness. An older complete and valid vault can be replayed; reliable rollback detection requires an independently protected reference to an accepted newer state.

Full German reference ↗

22Business and Enterprise permissions+

Owner, Admin, Editor and Viewer permissions are separate from actual possession of decryption keys. Collection Keys and device-bound envelopes isolate datasets; revoked users cannot be made to forget plaintext already learned.

Owner · Admin · Editor · Viewer

Full German reference ↗

23Key rotation+

Master password changes may only require rewrapping the unlock envelope. Secret Factor and vault epoch rotation are separate operations. A compromised data key may require fresh data encryption, not only rewrapping.

Full German reference ↗

24Backup and disaster recovery+

A recoverable backup includes metadata, envelopes, commits, records, chunks and the required recovery material. It must represent a consistent authenticated commit, and restoration must check completeness.

Full German reference ↗

25Deletion, tombstones and garbage collection+

Deletion is represented by authenticated tombstones; older encrypted revisions may remain for synchronization or recovery. Garbage collection respects offline devices, retention and backups. Physical erasure across SSDs and clouds is not guaranteed.

Full German reference ↗

26Private keys and reauthentication+

Exporting a private SSH key is a sensitive operation requiring Rust-side authorization, not merely a UI dialog. Exports must be bound to a specific permitted action and fail closed when reauthentication fails.

Full German reference ↗

27Runtime protection+

Locking discards controlled session secrets and zeroization reduces residual secret lifetime in Rust-owned buffers. Copies may still exist in the UI, clipboard, OS memory, swap or crash dumps; a compromised endpoint remains a limit.

Full German reference ↗

28Privacy and zero knowledge+

Storage providers do not require vault-decryption keys. However, ciphertext sizes, timings, object counts, IP addresses and transport metadata may remain observable. Optional website-icon fetching can reveal requested domains.

Full German reference ↗

29Software supply chain and dependencies+

Audit scope covers direct and transitive dependencies, feature flags, build configurations, exported interfaces and the actual release binary. Advisories and yanked versions must be assessed in context.

Full German reference ↗

30Threat model+

Explicit scenarios include vault theft, factor theft, ciphertext tampering, cross-vault substitution, crash, full disk, malicious provider, conflicting writers, rollback and compromised clients. Each scenario has a mechanism and a residual boundary.

Full German reference ↗

31Security audits and verifiability+

Independent review needs testable protocol contracts: KDF profiles, salt and nonce rules, AAD encoding, record and commit formats, error handling, filesystem persistence, multi-writer authorization, recovery and deployment-specific builds.

Architecture → Implementation → Tests → Platform → Independent review

Full German reference ↗

32What VORQYN does not promise+

VORQYN does not promise absolute endpoint security, guaranteed data survival, physical erasure from all media, perfect metadata secrecy, automatic rollback detection without an independent anchor or equivalence of unit tests and certification.

Full German reference ↗

33Frequently asked questions+

The answers distinguish stolen ciphertext from stolen credentials, Secret Factor protection from broad MFA claims, local offline access from cloud dependency, and cryptographic integrity from freshness.

Full German reference ↗

34Security by architecture+

Argon2id, a random Secret Factor, HKDF purpose separation, XChaCha20-Poly1305, independently wrapped DEKs, AAD, immutable records, authenticated commits and recoverable storage combine into a lifecycle security model.

Full German reference ↗

Security engineering

Security is an architectural decision.

Transparent cryptography, explicit trust boundaries and verifiable data flows shape VORQYN. Each mechanism has a distinct role, from the master password to an authenticated commit.

Back to home ↗