Built with care

You trust it with your files and passwords, so the parts you never see get the most care.

With AI, finding a program's weak spots and crafting files that hit them has become faster and cheaper. Compressed files arrive by mail and download, and are hard to inspect before opening: they have long been a way in for attackers.

Vault-ZIP follows six principles. None of them is "we were careful"; each is a mechanism or a test you can check.

1. A language that makes flaws hard to write (Rust)

Microsoft and Google have reported that about 70 % of the serious vulnerabilities in their products come from memory mistakes: reading or writing outside a buffer, using memory after it was freed, and so on. These mistakes are common in software written in C and C++.

Vault-ZIP's own code is written in Rust, a language that finds and stops such memory mistakes when the program is built. Most of the code that touches data from outside (compression, extraction, cryptography, name checks, the ledger) is Rust.

To be honest, not everything is Rust. RAR extraction (the RAR author's library), the ledger's encrypted database (SQLCipher) and the window component (Microsoft WebView2) are written in C or C++. RAR extraction has been fed 42,000 damaged RAR files without a crash.

2. Every incoming file is treated as hostile

• Nothing outside the folder: names with ../ or absolute paths are stopped before anything is written.
• No links: symbolic links and junctions that point elsewhere are never created.
• No disguises: names that hide their real extension with invisible characters, such as a name shown as invoiceexe.pdf that is really an .exe program because an invisible character (U+202E) reverses part of it, are replaced and reported.
• Headers are not trusted: Vault-ZIP counts the bytes it writes and stops files that swell abnormally (ZIP bombs), whatever the header claims.
• No crash on damaged files: a problem while reading stops with an error, and no partial file is left as if it were complete.

3. Testing the way attackers do (fuzzing)

Fuzzing feeds a program huge numbers of machine-made broken files and odd names, looking for crashes. It is how attackers and AI look for flaws; we do it before shipping.

• Extraction: 35 minutes of damaged archives
• File-name rules: 185,581 names in 300 seconds
• PDF encryption: 31,581 PDFs in 900 seconds
• File identification: 900 seconds

No crash, hang or memory error has been found (run with a memory-error detector). Automated tests that recreate each known trick of hostile archives run on every change.

4. No connection on its own

Without a way onto the network, there is nothing to attack from outside and nothing to leak. Vault-ZIP has no automatic update check, no usage reporting, no licence check over the network and no account.

The background traffic of the window component (Microsoft WebView2) is switched off too. In our measurement, nothing left the PC in the first 100 seconds after start.

5. Passwords that do not leak

• Never on the command line: the command-line tool takes passwords only through standard input, because command lines can be read by other programs, logs, and the records of AI agents and RPA tools you hand work to.
• Never in logs or errors: passwords live in dedicated containers that are wiped from memory after use, and never appear in logs, error messages or JSON output.
• An identity check before showing: a ledger password appears only when you press "Show", after Windows Hello or a similar check.
• Not left on the clipboard: a copied password stays out of the clipboard history and cloud clipboard and is cleared after a while.
• Not on screen captures: an option keeps a window showing a password out of screen sharing, recordings and screenshots.

6. Nothing broken, tampering noticed

• No overwriting: a taken name gets " (2)". Even when you choose to replace, the new file is finished under another name and swapped in one step, so a failure leaves the old one intact.
• Checked before done: the new ZIP is read back to make sure every file comes out as it went in. Originals go to the Recycle Bin only after that check, and only if they still match the ZIP.
• Tampering noticed: an AES ZIP fails if any file's check value (HMAC) does not match. This shows the encrypted data has not changed; it does not prove who made the file.
• The ledger is not lost: a failed backup import leaves the current ledger and key untouched, and a missing key is never replaced by a new one over an existing ledger.

What Vault-ZIP cannot do

• File names inside a ZIP are not encrypted; the ZIP format does not allow it. To hide names too, put the ZIP inside another ZIP.
• Encryption is as strong as the password. Generated passwords are recommended.
• If the PC itself is taken over (for example by malware with administrator rights), no software can protect you. Vault-ZIP is not a replacement for antivirus software.
• It is not code-signed yet. Check downloads against the SHA-256 values (download).

To report a vulnerability, see Security.