Skip to content
VaultKeepR

Cryptography

The cryptography lives in @vaultkeepr/core, published to npm under the MIT license. The primitives come from @noble/ciphers, @noble/curves, and @noble/hashes; the package does not implement its own cipher math.

Key derivation

Section titled “Key derivation”

The app derives the vault encryption key from your master password with Argon2id using these parameters:

ParameterValue
Time cost (t)3
Memory cost (m)64 MiB
Parallelism (p)4

These values are asserted in the package tests, so a drift in the parameters fails CI rather than shipping silently. The master password is never transmitted or stored; it exists in your memory and briefly in device memory during derivation. A random salt is generated per vault (generateSaltArgon2).

Encryption

Section titled “Encryption”

Vault plaintext is encrypted with XChaCha20-Poly1305, an AEAD cipher, with random nonces. Ciphertext is what leaves the device for sync, backup, or pinning. Vault integrity is enforced with an HMAC-SHA256 commitment: tampering with a vault blob makes decryption throw instead of returning modified data.

encryptVault and decryptVault wipe the master key after use by default (wipeKeyAfterUse). Decryption requires re-deriving the key from your password each time.

ECIES envelopes

Section titled “ECIES envelopes”

Some secrets travel between parties, for example a master key sealed for a legacy beneficiary. The core uses ECIES with secp256k1 keys for these envelopes: the sender encrypts to the recipient’s public key, and only the recipient’s private key can open it. Session and delegation signatures follow EIP-4361 schemas, implemented in @vaultkeepr/wallet-messages.

Other surfaces in the core

Section titled “Other surfaces in the core”
  • TOTP: getTOTPCode and parseTOTPUri for two-factor codes
  • Passkey, NFC, and MRZ crypto
  • Password generation, health checks, and entropy estimation
  • BIP-39 and EFF wordlists
  • Import and export for 10+ password manager formats (Bitwarden, 1Password, LastPass, Keeper, Dashlane, Enpass, KeePass XML, RoboForm, Proton Pass, and others)
  • A three-way merge and pairing helpers

The test suite for the package covers tampering resistance and v2/v3 key separation, among other cases (510 tests across the repository at the time of the security assessment).

Why these primitives

Section titled “Why these primitives”

The project does not write its own cipher code. Ciphers, curves, and hashes come from the @noble/* libraries, and viem supplies the Ethereum types and clients. Lockfiles pin the dependency versions and CI installs them frozen, so a dependency change is a reviewed change rather than a silent one. The security assessment lists supply-chain compromise of @noble/* or viem as a tracked risk and documents its mitigations: frozen installs, SHA-pinned CI actions, secret scanning with push protection, and Dependabot weekly updates.

Source files

Section titled “Source files”