Security

What Loclavis does technically, and what it does not. Only properties that can be checked in the code are listed here.

Local processing

Encryption and decryption run in your browser, inside a web worker. The files you protect are not uploaded.

Algorithms in use

• AES-256-GCM for contents and metadata, with separate keys.
• Argon2id (64 MiB, 3 passes) to derive keys from your password.
• HKDF-SHA-256 to separate the wrap, metadata and stream keys.
• For ordinary PDFs, optional native AES-256 encryption via qpdf (WebAssembly, bundled locally).

What a container reveals

The public header of a .safe container holds the salt, the algorithm parameters and size information. Filename, folder structure and contents are encrypted inside it.

Which online functions exist

Payment and licence checking. Both are separated from the encryption core and never transmit files, passwords or keys.

How local processing works technically

• The browser provides file APIs. A selected file is a File object from which slice() reads individual sections without pulling the whole file into memory.
• Web Crypto (crypto.subtle) provides AES-256-GCM and HKDF-SHA-256 as native browser implementations. The key is imported as a non-extractable CryptoKey object, after which its raw material can no longer be read from JavaScript.
• Argon2id runs as a WebAssembly module, because the computation is deliberately expensive. For native PDF encryption qpdf is loaded as WebAssembly, bundled locally rather than fetched from someone else's server.
• Encryption runs in a web worker, that is its own thread. The interface stays responsive, and the worker only ever sees the header and one section, never the whole file.
• Processing happens in sections of about 1 MiB. Each section is read, encrypted, written and released again, so memory use does not depend on the size of the file.
• Where the browser supports it, the result is written straight into the file you picked through the File System Access API. Otherwise a Blob is created and offered as an ordinary download.

Authenticated encryption and tamper detection

• AES-GCM produces an authentication tag for every section. It is verified on decryption before any plaintext is handed back.
• The format version, the section index and the final-section marker are folded into that check as well, so swapped, removed or duplicated sections are detected.
• The number of sections is recorded in the encrypted metadata. Data appended to the end of the file causes the operation to stop.
• If any check fails, the output is discarded. No half decrypted file is ever saved.
• The error message does not distinguish a wrong password from a damaged file. A more precise message would be free help for an attacker.

Structure of the protected file

• The public header holds the magic bytes, the format version, the Argon2id parameters, a random salt, a random prefix for the nonces, the section size, and the encrypted metadata and encrypted data key.
• Argon2id turns the password into a master key. HKDF-SHA-256 derives a wrapping key from it. A random data key is generated per container and wrapped with that; separate keys for metadata and content are derived from the data key.
• Filename, original size and section count live in the encrypted metadata block, not in the header. Only algorithm parameters and rough sizes are visible.
• For several files an archive is streamed locally and encrypted as a whole, which puts paths and names inside the encrypted region too.

The native PDF path

• For ordinary PDFs, qpdf produces a PDF encrypted with AES-256 as defined by the PDF standard. The recipient opens it in a suitable reader and enters the password.
• Key derivation here is dictated by the PDF standard. It is considerably faster to attack than Argon2id, which is why Loclavis requires a stronger password on this path.
• PDF/A and ZUGFeRD documents are detected and stored unchanged inside a protected file instead, because later encryption can damage their structure.
• qpdf needs SharedArrayBuffer and therefore a cross-origin-isolated page. Without the corresponding HTTP headers, Loclavis reports the PDF path as unavailable and falls back to the protected file.

Password generator

• Randomness comes only from crypto.getRandomValues. Math.random, timestamps and counters are not used.
• Selection from the character set and the word list discards values outside the uniform range and draws again. A plain modulo would favour the lower indices.
• Generated passwords are not stored, not logged and not transmitted. There is no password history.
• The standard password carries around 120 bits of randomness. A passphrase from the 512 word list carries exactly 9 bits per word.

Offline behaviour

• Once the page has loaded, encrypting and decrypting need no connection. This is measured: load the page, switch the network off, protect a file and decrypt it again works completely.
• The program parts an operation needs are fetched in the background after the first render, so they are already present when required.
• Loclavis is not an installed offline application. There is no service worker, and reloading the page without a connection does not work.

What happens server side

• Delivering the website. Technically necessary access data is recorded by the host in the process.
• When buying Plus you are redirected to Stripe. You enter your payment details there; we neither see nor store them.
• During a licence check the browser sends only the Plus key to our own verification function, which validates the signature and asks Stripe about the subscription status.
• A donation link, once configured, leads to an external provider. It is only contacted when you click it, and it receives nothing about your operation.
• Never transmitted: files, file contents, filenames, passwords, derived keys and protected containers.

Losing the password

There is no recovery. Without the password the contents cannot be reconstructed, not by us either. There is no second key, no back door and no procedure that gets around it.

Limits

• Security depends on your device and browser. No web application helps on a compromised system.
• A weak password stays a weak password. Argon2id makes guessing expensive, not impossible.
• JavaScript cannot guarantee that memory is overwritten. Key material is wiped on a best-effort basis.
• Loclavis has not been externally certified. There is no security seal and no guarantee.