1. Master key derivation (PBKDF2)
Upon account creation, a random 16-byte cryptographic salt is generated. The user's master password is combined with this salt and processed using PBKDF2. We use 600,000 iterations of HMAC-SHA256 to derive a 256-bit symmetric master key.
2. Authentication hash
To authenticate without transmitting the derived master key, the client hashes the raw 256-bit master key using SHA-256. This AuthHash is sent to the server as a bearer credential — the master key itself never leaves the device.
3. RSA asymmetric keypair generation
The client generates an RSA-OAEP 2048-bit public/private keypair. The private key is immediately encrypted using the symmetric 256-bit master key via AES-GCM with a random 12-byte IV. Only the encrypted private key and the plaintext public key are ever stored on the server.
4. Vault item encryption (AES-GCM)
Every vault item — a login, card, or secure note — gets a randomly generated 256-bit item key. The item payload is encrypted with that key via AES-GCM.
To support sharing, the item key itself is encrypted with the RSA public key of the vault owner. On decryption, the client fetches the RSA-encrypted private key, decrypts it with the master key, then uses the private key to decrypt the item key, which finally decrypts the payload.
5. Recovery without a support ticket
A one-time recovery code, shown once at account creation, derives its own recovery key using the same PBKDF2 process. That key can decrypt a second copy of your RSA private key, re-encrypted under your new master password during recovery. VoidCove never stores the recovery code itself — only what it derives.
The golden rule
Because the master password never leaves the client, and the RSA private key can't be decrypted without it, VoidCove has zero access to your encrypted vault payloads. A compromise of our database yields mathematically useless ciphertext.