← Back to MOTI

Technical architecture

Security model

MOTI encrypts secrets in the browser and is designed so the backend does not need to know your values or decryption keys.

01 / Encryption hierarchy

Encryption hierarchy

Each layer has a specific responsibility. The password does not encrypt secrets directly, and the API never receives a decrypted vault key.

01

Password

The user's password is used to create the key-encryption key. It is never stored or sent to the backend.

02

Key-encryption key (KEK)

Argon2id derives a wrapping key from the password and its derivation parameters.

03

Encrypted decryption-key key

The key-encryption key protects each vault's decryption-key key before encrypted material is stored.

04

Decryption-key key (DEK)

Each vault has an independent data key that encrypts its values.

05

Secret ciphertext

AES-256-GCM encrypts each value with a unique IV and produces an authentication tag.

02 / Trust boundary

Trust boundary

The server stores the material needed to synchronize and operate the account, but it does not receive plaintext secrets.

+The server can store

  • ✓Ciphertext for each secret
  • ✓IV and authentication tag
  • ✓Encrypted decryption-key key
  • ✓Argon2id parameters
  • ✓Account and vault metadata

×The server does not receive

  • ×The user's password
  • ×Plaintext secrets
  • ×The decrypted decryption-key key
  • ×A usable key-encryption key
  • ×Original .env values

03 / Sensitive operations

Sensitive operations

Password change

The client unlocks the hierarchy locally, creates a new key-encryption key, and protects the vault key again. The backend receives updated encrypted material.

Recovery

The recovery file restores the hierarchy without asking the server to decrypt the vault. Losing both password and recovery can mean irreversible loss of access.

This document describes the implemented model and does not replace an independent security audit.