VAULT / SECURITY DESIGN / 1.0.0
Trust starts
with the details.
What the vault protects, how it works, and which assurances still need evidence.
01 / SCOPE
A precise security claim.
Aftercurve Vault is local software for encrypted passwords, API keys, private notes, and recovery codes. Encryption protects copied stored vaults and exported backups against disclosure, subject to password strength and implementation correctness. Offline transfers use a fresh recipient key and require independent fingerprint verification.
The implementation has automated tests and published source. It has not received an independent security audit or actual-browser validation in this build environment. The ML-KEM dependency also does not claim an independent audit. This downloadable package is not a signed extension-store release.
A compromised operating system, browser, extension page, or update can expose unlocked secrets. A website receives and can read a credential deliberately filled into it. This software does not secure Ethereum transactions, replace a hardware wallet, repair weak master passwords, or guarantee protection from every future quantum attack.
02 / ENCRYPTION
Established primitives.
Explicit parameters.
| LAYER | IMPLEMENTATION |
|---|---|
| Vault encryption | Web Crypto AES-256-GCM. Random 256-bit data key; fresh random 96-bit nonce per encryption; 128-bit tag. |
| Master-password derivation | Argon2id v1.3: 64 MiB, 3 passes, parallelism 1, 32-byte salt and 32-byte output. A fixed browser profile, not the exact parallelism-4 profile in RFC 9106. |
| Key wrapping | AES-256-GCM wraps the data key under the password-derived key. A password change creates a fresh data key and salt and reencrypts the full vault. |
| Authenticated context | Format, version, vault ID, purpose and KDF parameters are bound to key wrapping. Vault data additionally binds revision and the complete wrapped-key object. |
| Input limits | 10 MiB files, 6 MiB canonical plaintext, 5,000 entries, fixed cryptographic lengths and strict allowed fields. Unknown versions and derivation profiles are rejected. |
Titles, websites, usernames, notes, settings, and pending transfer private keys are encrypted. Algorithm metadata, salts, nonces, vault ID, revision, size, and ciphertext remain visible. A long, unique master password matters: the KDF makes guessing more expensive but does not create entropy that the password lacks.
Old backups retain their original password and cannot be revoked remotely. Backups deliberately omit pending device-transfer private keys. Export a fresh backup after rotating your password.
03 / BROWSER BOUNDARIES
Local, with narrow permissions.
Decrypted data and the live data key reside in a dedicated extension worker. Requested entry details also enter the extension UI. Locking terminates the worker and clears displayed secrets. This helps contain accidental exposure; it is not a boundary against malicious extension code, and JavaScript cannot guarantee memory erasure.
The vault checks idle time on each privileged operation and with a timer, using both wall and monotonic time. It locks when its tab is hidden and requires unlocking after reload or restart. Late operation replies are invalidated by lock-generation checks.
A trusted extension-page-only background handler serializes ciphertext writes and compares the previous envelope hash and revision. Stale tabs cannot silently overwrite a newer saved vault. Save failures are reported, and browser storage is restricted to trusted extension contexts.
Autofill is an explicit action.
The toolbar button creates a single-use, ten-minute permission tied to the source tab and its exact HTTPS origin, including port. The entry must match. The background and injected top-frame function recheck the destination; the fill function rejects cross-origin form actions and submit-button overrides, ambiguous fields, hidden or read-only fields, and new-password forms. It does not submit forms.
There are no permanent host permissions, installed content scripts, external messaging listener, remote code, embedded frames, telemetry, or fetch calls. The extension CSP blocks network connections. See the privacy and permissions page ↗.
Autofill intentionally does not cover every website, shadow DOM, iframe, username-first flow, or cross-origin identity provider. Clipboard contents may remain accessible to other applications; automatic clipboard erasure is not claimed.
04 / DEVICE TRANSFER
Verify both ends.
The receiving device creates a fresh ML-KEM-768 keypair and a receive request with a 30-minute lifetime. The sending device must compare the complete SHA-256 request fingerprint obtained directly from the receiving device or through a trusted separate channel.
ML-KEM encapsulation establishes a secret. HKDF-SHA256 derives an AES-256-GCM key using the request hash and a versioned domain string. GCM authenticates the payload and transfer headers, including the recipient request and KEM ciphertext.
The receiving device separately verifies the complete SHA-256 package fingerprint supplied by the sender through a trusted channel. ML-KEM alone does not authenticate who sent a package. Copying fingerprints from the untrusted files themselves defeats the purpose of verification.
Entries are previewed before import and added without overwriting existing records. A saved import consumes and removes the one-time receive key. Ordinary backups cannot restore those keys; restoring an entire old browser profile remains outside the rollback model. Expiry assumes a reasonably correct device clock.
ML-KEM-768 is standardized by FIPS 203. The complete Aftercurve transfer format and fingerprint workflow are application-specific and have not received independent protocol review. Standardization of the primitive is not certification of this product.
05 / VALIDATION
Evidence you can inspect.
Executed on 12 October 2026 with Node 24.19.0. The suite includes an RFC 9106 Argon2id vector, a subset of final FIPS 203 ACVP ML-KEM cases, encryption and tamper checks, worker integration, backup/restore, key rotation, transfer/replay, mocked Chrome storage/permission boundaries, DOM models for autofill, and static package checks. The dependency result is a point-in-time npm advisory check.
These checks are not a NIST validation, independent audit, browser certification, or proof of complete security. Browser installation, rendering, accessibility, restart/suspension, real-site autofill, and cross-device behavior still need actual-browser testing. Signed store distribution and independent application and cryptographic review remain outstanding.
06 / SOURCE & REFERENCES
Read the foundations.
These specifications and projects inform the implementation. Their authors do not endorse or certify Aftercurve.