Encryption Overview

Bittery uses industry-standard cryptographic primitives, composed carefully to provide defense-in-depth. Here's what's under the hood.

Cryptographic primitives

Primitive	Algorithm	Usage
Symmetric encryption	AES-256-GCM (`AES-GCM-AAD-V1` format)	Vault items, vault keys, private keys
Key derivation	PBKDF2-SHA256 (310k iter)	Derive keys from master password
Key expansion	HKDF-SHA256	Split derived key into auth + unlock keys
Asymmetric encryption	RSA-4096 OAEP	Vault sharing between users
Authentication	SRP-6a	Password-authenticated key exchange
Login hardening	KDF policy + local pinning	Detect and block KDF downgrade/tampering

AES-256-GCM with Context Binding

All sensitive data is encrypted using AES-256-GCM (Galois/Counter Mode). Serialized ciphertexts use algorithm identifier AES-GCM-AAD-V1.

GCM provides both confidentiality and authenticity, and Bittery also binds entity metadata to item/attachment payloads so ciphertext cannot be swapped between entities without verification failure.

Key properties:

256-bit keys — considered secure against quantum computers with Grover's algorithm (still 128-bit security)
Random 96-bit IV per encryption — generated using a cryptographically secure random number generator
Authentication tag — ensures data integrity
Deterministic context binding — item and attachment payloads bind vaultId, entityId, entityType, version, and userId

SRP-6a Authentication

Rather than sending your password to the server (even hashed), Bittery uses the Secure Remote Password (SRP-6a) protocol:

During sign-up, a verifier is computed from your auth key and stored server-side
During login, a zero-knowledge proof exchange occurs — the server confirms you know the password without ever seeing it
A shared session key is derived, used to establish the authenticated session

Tip

SRP-6a is resistant to man-in-the-middle attacks and server compromise. Even if an attacker captures the verifier, they cannot derive your password from it.

Login KDF Policy and Pinning

During login challenge (startLogin), the server returns explicit KDF parameters (schemaVersion, algorithm, iterations, salt).

Clients enforce:

algorithm must be pbkdf2-sha256
iterations must stay at or above the minimum policy
salt format and length must be valid
After first successful login, pinned values are stored locally and future downgrades/changes are rejected

RSA-4096 for Sharing

When you share a vault with another user:

The vault key is encrypted with the recipient's RSA-4096 public key
Only the recipient's corresponding private key (which is encrypted with their own Master Unlock Key) can decrypt it
The sharing user never has access to the recipient's private key

This means vault sharing works without exposing any party's master password or encryption keys.

Implementation

All cryptographic operations are implemented in Rust and compiled to platform-specific bindings:

Web & Extension: WebAssembly (WASM)
Desktop: Tauri commands (native Rust)
Server: Native Rust
Mobile: Expo native module

This ensures consistent, auditable cryptography across all platforms with no JavaScript crypto dependencies.

Open source

The entire crypto implementation is public and available for audit at github.com/bittery-org/bittery. We believe transparency is fundamental to trust in a security product.