By V · Published 23 October 2026 · Experimental project notes
By V · 23 October 2026. This is an implementation note for the experimental VVAULT version 1 format, reviewed in the VVault 0.2.9 source. It is not a new cryptographic protocol recommendation or an independent security assessment. Use synthetic data only.
From text to an authenticated package
VVault encodes the message as UTF-8 and generates a fresh 16-byte salt and 12-byte IV using browser Web Crypto. PBKDF2 with SHA-256 and 600,000 iterations derives a non-extractable 256-bit AES key from the passphrase and salt. AES-GCM encrypts the message with a 128-bit authentication tag.
The additional authenticated data is the fixed string VVAULT:1:PBKDF2-SHA256:600000:AES-256-GCM. It binds this operation to the expected format and algorithm suite. The salt and IV are public parameters, not secrets. Their presence in the package is intentional.
The envelope contract
The JSON package has exactly eight members: format, version, kdf, iterations, cipher, salt, iv and ciphertext. Algorithm identifiers and iteration count must match the supported constants; the parser does not accept arbitrary caller-selected parameters.
Input is bounded to 200,000 JavaScript string characters. Decoded plaintext is capped at 128 KiB of UTF-8 bytes. Salt and IV lengths are checked, and binary fields must have canonical base64 spelling. Duplicate top-level JSON names, including escaped equivalents, are refused so different parsers cannot silently select different values.
Wrong password and altered data
The decrypt operation validates the package before deriving the key. AES-GCM authentication failure produces one message: the passphrase is wrong or the package changed. The interface does not claim it can reliably distinguish those causes. Successful output uses strict UTF-8 decoding and preserves an authenticated leading Unicode marker.
What the passphrase requirement means
Encryption requires at least 14 JavaScript string characters and accepts at most 1,024. Length is not entropy: a predictable long phrase can still be guessed. PBKDF2 adds work to each attempt but does not turn a weak passphrase into a strong one. A captured package supports offline guessing; there is no server-side login limit to protect it.
Limits of the construction
Knowing the shared passphrase permits creating a valid package, so authentication of ciphertext integrity is not authentication of a particular person. VVault has no sender identity, recovery or forward secrecy. A compromised browser or origin can defeat the workflow. The implementation wipes owned byte buffers where practical, but cannot guarantee removal of JavaScript strings or OS/browser copies.
Review and reproduce
Inspect the encryption and parser code, then run the repository’s Node tests against a recorded revision. A passing suite covers its cases; it does not prove the absence of other flaws. See the source links below and report sensitive findings privately through the reporting route.
← All guides · Share test feedback ↗
Keep exploring
- Offline integrity: verifying bytes is only half the response
- V Cipher: QR transport, message authentication and replay boundaries
- Development log 01: key handling and offline integrity
- Development log 02: making release evidence easier to check
- Development log 03: the validation work still ahead
- How to test local message encryption with VVault
- How to transfer ciphertext without sharing the passphrase
- An Android app-firewall test checklist for VGuard
- How to read security claims before testing a privacy app