Security & Trust

Security is not a feature. It's the foundation.

Selvum is built on the principle that the best way to protect your data is to never touch it in the first place.

2^128
Valid seed combinations
0
Selvum servers storing your data
THREAT MODEL

What Selvum protects you from.
And what it doesn't.

Honest security means defining the boundaries clearly.

Protected against

Cloud breaches

There are no Selvum servers to breach. Your vault never leaves your device.

Network attacks

Selvum is 100% offline. No data in transit means no interception possible.

Provider access

Selvum has no access to your vault because it never receives your data. Not even with a court order.

Weak encryption

AES-256-GCM, with the encryption key derived from your seed phrase's 128-bit entropy in every configuration — Android adds Argon2id (memory-hard) as extra hardening on top. Modern cryptographic standards, widely audited and used in high-security systems.

Out of scope

Compromised device

If your device is rooted or has malware, no password manager can fully protect you. Selvum detects and warns you.

Lost seed phrase

Your 12 words are your only key. If you lose them, no one can recover your vault. This is by design.

Physical coercion

If someone forces you to unlock the app, that is outside the technical threat model of any password manager.

Device theft while unlocked

Selvum auto-locks after inactivity. Always lock your phone screen.

CRYPTOGRAPHY

The math behind your security.

KEY DERIVATION

Adaptive key derivation

output = 256-bit key entropy = 128 bits (seed) class = memory-hard (Android only) fallback = PBKDF2-SHA512 (iOS / Kit)

The core defense is your seed phrase's 128-bit entropy — brute-forcing it is computationally infeasible on any platform. Android additionally uses a memory-hard KDF (Argon2id) for extra GPU/ASIC resistance.

App on Android: Argon2id · 64 MB memory · 3 iterations · parallelism 1. App on iOS and Recovery Kit (both platforms): PBKDF2-HMAC-SHA512 · 600,000 iterations — the Recovery Kit's zero-dependency design rules out bundling Argon2id, and iOS mirrors that choice for consistency. The seed phrase's 128-bit entropy makes brute-force infeasible in both cases.

ENCRYPTION

AES-256-GCM

key_size = 256 bits nonce = random per operation auth_tag = 128 bits mode = authenticated

Authenticated encryption. Any tampering with the encrypted contents is detected before a single byte is returned.

SEED PHRASE

BIP-39 Standard

wordlist = 2,048 words words = 12 combinations = 2^132 entropy = 128 bits

The same standard securing billions in cryptocurrency. The search space is so large that a brute-force attack is impractical with current technology.

OPEN SPECIFICATION

The .sv file format is fully documented.

You don't have to trust us. You can verify the format, inspect the file and check how recovery works.

RESCATE_OFFLINE.html is plain, unobfuscated JavaScript — open it in any text editor to audit the full decryption logic.

// Selvum Vault Format v1.0
// Every .sv file follows this structure:
[4 bytes] Magic: 0x53 0x45 0x4C 0x56 // "SELV"
[2 bytes] Version: 0x00 0x01 // v1.0
[1 byte ] Flags: KDF selector (0x00/0x01)
[16 bytes] Salt: KDF salt (random)
[12 bytes] Nonce: AES-GCM nonce (random per save)
[4 bytes] Length: payload size (big-endian uint32)
[N bytes] Payload: AES-256-GCM ciphertext (last 16 bytes are the GCM tag)
// Decrypted payload is valid JSON.
// Without the 12-word seed phrase,
// decryption is computationally impossible.
VERIFICATION KIT

Verify it yourself.

A real vault. Known seed. Decrypt it yourself.

Download this example Recovery Kit generated with real data. Open RESCATE_OFFLINE.html in any browser — no internet, no app needed — and enter the 12 words below. You will see the decrypted entries. This is exactly how your vault works.

01index
02rug
03subway
04raccoon
05space
06pole
07glow
08nephew
09bulk
10possible
11iron
12canoe
DESIGN DECISIONS

Every security decision has a reason.

Why no cloud sync?
Any server storing encrypted vaults is a target. By eliminating servers entirely, we eliminate the entire attack surface.
Direct consequence of the security model
Why do the same 12 words decrypt both the app and the Recovery Kit?
The BIP-39 seed phrase is the only master key to your vault. The app and RESCATE_OFFLINE.html both derive the encryption key from those 12 words — Android uses a memory-hard KDF (Argon2id), while iOS and the Recovery Kit use PBKDF2-SHA512. Either way, this guarantees that the Recovery Kit works without needing to remember any additional password — only the words you already have on paper.
Direct consequence of the security model
Why does Android use a different KDF than iOS?
RESCATE_OFFLINE.html is deliberately built as a single self-contained HTML file with zero external dependencies or bundled libraries — that's what lets anyone audit it by opening it in a plain text editor, with no third-party supply chain to trust in 2040. Bundling an Argon2id library, native or via JavaScript, would break that zero-dependency principle. That's why both iOS and the Recovery Kit use PBKDF2-SHA512 with 600,000 iterations, keeping the two consistent. Android has no such constraint, so it uses Argon2id — the stronger KDF — instead. Either way, the real defense against brute-force isn't the specific KDF: it's the 128 bits of entropy in your seed phrase, which both derive their strength from.
Direct consequence of the security model
Why doesn't Selvum store anything to verify your seed phrase?
Verification does happen — just not by storing anything. Your twelve words carry 128 bits of entropy plus a 4-bit checksum derived from them — 132 bits in total, which is exactly what the twelve words encode. That checksum catches a mistyped word before any decryption is even attempted. If the seed is wrong in a way the checksum misses, the derived key is wrong too. When unlocking or importing, the AES-256-GCM authentication tag fails, telling you the seed is incorrect. When exporting, the derived key is compared directly against the vault's actual master key instead — same outcome, different mechanism, because no decryption happens at that step.
Direct consequence of the security model
How does Selvum protect the clipboard?
Selvum marks all copied content as sensitive so it is hidden from clipboard history and cannot be read by other apps.
Intentional
Why not use an existing vault format (like KDBX)?
Existing formats like KDBX are mature and battle-tested, but they're built for feature-rich, extensible password managers with plugin ecosystems. The Recovery Kit's core requirement was different: it has to be small enough to read and audit in full, in plain JavaScript, with zero dependencies. A minimal custom format kept that goal achievable. The tradeoff is explicit: less interoperability with other tools, in exchange for a recovery path simple enough that anyone can verify exactly what it does before trusting it.
Direct consequence of the security model
Why NFC and not NFKD, as BIP-39 specifies?
BIP-39 mandates NFKD for its own seed derivation — the step that turns a mnemonic into a binary seed via PBKDF2 with a fixed salt. Selvum doesn't use that step: the twelve words go straight into the key derivation function as the passphrase, so the choice of normal form is ours to make. NFC is what phone keyboards emit, and it's how the BIP-39 wordlists shipped with the app are stored — the form users actually produce when they type their phrase.
Direct consequence of the security model
IMPLEMENTATION

What we've implemented.
Nothing hidden.

AES-256-GCM authenticated encryption
Auto-lock on background
Strong key derivation (Argon2id on Android, PBKDF2-SHA512 elsewhere — both hardened by the seed's 128-bit entropy)
Android cloud backup disabled
Random nonce per save operation
iOS iCloud backup excluded
Screenshot prevention (FLAG_SECURE)
Root/jailbreak detection
Clipboard protected — content hidden from clipboard history
Zero network permissions
Biometric authentication via device OS
Zero analytics or telemetry
Publicly documented vault format
Recovery Kit export verifies your phrase against the vault before encrypting
RESPONSIBLE DISCLOSURE

Found a vulnerability?

If you discover a security vulnerability in Selvum, please report it to security@selvum.app. We will respond within 72 hours. We handle all reports seriously and responsibly.

Audit the security-critical code yourself:

https://github.com/selvumapp/selvum-security-audit

© 2026 — Selvum