Encryption and storage

Every kubbi is encrypted before it touches storage. Plaintext payloads never sit in the database.

Algorithm

AES-256-GCM with a unique IV and authentication tag per payload. Multi-file packages encrypt each file individually.

Keys and per-payload uniqueness

kubbi uses a service-wide AES master key. Per-payload cryptographic uniqueness comes from a fresh 12-byte initialization vector (IV) and a 16-byte GCM authentication tag generated for every encryption.

When a kubbi reaches a terminal state (expired, burned, or deleted), the ciphertext, IV, and auth tag stored on the row are overwritten server-side. The decryption material for that specific payload is gone.

Tokens and credentials

Claim tokens and API keys are SHA-256 hashed before storage. The raw values exist only in the claim URL (for tokens) or in the once-shown response at creation (for API keys). They cannot be recovered.

Dashboard passwords are hashed with bcryptjs. (Account passwords live in the dashboard; the public API does not handle passwords.)

Payload wiping

When a kubbi is burned, deleted, or expired, the encrypted payload, IV, and auth tag columns are overwritten atomically with the status update (a single SQL UPDATE). Not just deleted, overwritten.

For the full security posture (access model, HTTPS enforcement, CORS, rate limiting, logging, health checks), see Security & Operations.