How Reiven protects shared content
Reiven is designed to encrypt payload contents before upload and decrypt them on the recipient’s device. This page describes the implementation and its boundaries.
Encryption on your device
The browser generates a random 256-bit data encryption key and encrypts payloads with AES-256-GCM. Large files are encrypted in chunks with separate nonces. Passwords are processed with Argon2id to derive a seed for a deterministic ML-KEM-768 keypair. An ML-KEM shared secret is used to wrap the data key.
The Standard profile uses Argon2id with 4 iterations, 64 MiB memory, and parallelism 1. Paranoid uses 6 iterations and 128 MiB. Both use PIM 100. The CLI shares the encryption configuration with the browser.
ML-KEM-768 supplies a post-quantum key-wrapping layer. This does not make weak passwords safe: someone holding ciphertext can attempt offline password guesses. Choose a long, randomly generated password or QR Mode's random key.
What the server receives
Normal application requests send encrypted payloads rather than plaintext contents or decryption passwords. The server also receives operational metadata, including the upload filename, encrypted size, file identifier, expiry, deletion token, receiver-deletion setting, note flag, access-code hash, and download count. Connections reveal network information such as IP addresses.
If the filename is sensitive, change it before uploading. “Zero knowledge” here describes the intended payload-encryption design; it does not mean the service sees no metadata. See privacy and logging details.
Temporary storage in memory
The application holds ciphertext and share metadata in process memory and does not write them to application-managed disk files. The hosted service disables swap use for the process and core dumps. Operational logs are separate and can be stored on disk.
Expiration and deletion remove the server's live records and buffers. Restarting the service removes all shares. This is not a promise of forensic memory erasure, and it cannot revoke a recipient's saved copy. Read the storage guide.
QR links and access
QR Mode puts its randomly generated key in the URL fragment, after #. Fragments are not sent as part of ordinary HTTP requests, but the full link remains a secret. It can be exposed in browser history, copied messages, screenshots, or software on a recipient's device.
A file link or access code identifies a share; the password or QR key decrypts it. A deletion link grants deletion access. Share these according to what you want the other person to be able to do.
Browser and server trust
Browser encryption still depends on the JavaScript served by the website and on your device. A compromised server could deliver altered code; a compromised browser can read what you type or decrypt. The sharing, receiving, download, and deletion pages do not load Google Analytics or other third-party scripts. Public information pages use Google Analytics.
The implementation is available in the Reiven source repository. This description is not an independent security certification. For support, use the project's public issue tracker without posting passwords, private links, or confidential content.