Loading...
Loading...
Cliprift protects your clipboard data with AES-256 encryption at rest, TLS 1.3 in transit, and automatic sensitive data detection. This page describes both the current security model and the end-to-end encryption architecture we are building.
Current protection
All clipboard data is encrypted at rest with AES-256 on our servers and transmitted over TLS 1.3. Sensitive content (passwords, API keys, credit cards) is automatically detected and can auto-expire. End-to-end encryption — where content is encrypted on your device before reaching our servers — is under active development. The architecture below describes how it will work when available.
Cliprift is building end-to-end encryption so that every clipboard item will be encrypted on your device before it reaches our servers. The encryption key will be derived from a passphrase that only you know. We will never receive, store, or have access to this passphrase or the derived key.
When enabled, even if our servers were compromised, an attacker would only find encrypted blobs that are computationally infeasible to decrypt without your passphrase. This is not a policy decision — it is a mathematical guarantee.
The encryption experience is designed to be invisible during normal use. You will enter your passphrase once per session, and everything else will happen automatically. Clipboard items will be encrypted before upload, decrypted after download, and displayed as normal.
With end-to-end encryption enabled, the server will have no ability to decrypt your data. Here is what the server will store versus what will stay on your device:
No backdoors by design
The architecture has no master key, no admin override, and no way for Cliprift staff to decrypt your data. If you lose your passphrase and all recovery codes, your encrypted data will be permanently inaccessible. This is by design.
Cliprift's E2E encryption uses AES-256-GCM for symmetric encryption — the same standard used by governments, banks, and security-critical applications worldwide. GCM mode provides both confidentiality and authenticity: it encrypts your data and detects any tampering.
Your encryption key will be derived from your passphrase using PBKDF2-SHA256 with 600,000 iterations, following the OWASP 2023 recommendation. This makes brute-force attacks computationally expensive — even with specialized hardware, testing each candidate passphrase takes significant time.
| Property | Value | Purpose |
|---|---|---|
| Encryption Algorithm | AES-256-GCM | Authenticated encryption with 256-bit keys |
| Key Derivation | PBKDF2-SHA256 | 600,000 iterations (OWASP 2023 recommendation) |
| IV Length | 96 bits | Unique random initialization vector per encryption |
| Auth Tag | 128 bits | Tamper detection on every encrypted block |
| Salt | 128 bits | Unique random salt per user account |
| Key Check | SHA-256 | Hash of derived key for passphrase verification |
You copy something
The clipboard watcher detects new content on your device.
Encrypted locally
The content will be encrypted with your AES-256-GCM key. A unique random IV will be generated for each item.
Uploaded as an opaque blob
The encrypted payload will be sent to the server. The server will store it without any ability to read the contents.
Synced to your other devices
Your other devices will download the encrypted blob and decrypt it locally using the same key derived from your passphrase.
When E2E encryption is available, you will enable it during onboarding or from Settings by choosing a passphrase. This passphrase will be the sole input to the key derivation process — there will be no separate "encryption key" to manage.
Your passphrase will need to be at least 8 characters. We recommend 12 or more characters with a mix of uppercase, lowercase, numbers, and symbols. A strength indicator will guide you during setup.
Your passphrase will be combined with a random salt through 600,000 rounds of PBKDF2-SHA256 to produce a 256-bit encryption key. This process will happen entirely on your device using the Web Crypto API. The passphrase will never be transmitted.
A SHA-256 hash of the derived key will be sent to the server as a "key check hash." This allows other devices to verify that you have entered the correct passphrase without ever revealing the key itself. The hash is one-way — the key cannot be reconstructed from it.
If you have existing clipboard items from before enabling encryption, they will be re-encrypted in batches. A progress bar will show migration status. No data will be lost during this process.
During encryption setup, Cliprift will generate 12 single-use recovery codes. These will be your backup if you forget your passphrase. Each code can restore full access to your encrypted data — but only once.
Example recovery code format
ABCD-EF23-GHKL12 alphanumeric characters in 3 groups. Characters that look similar (0/O, 1/I) are excluded to prevent entry errors.
How recovery codes will work under the hood: During setup, the raw encryption key will be wrapped (encrypted) with a key derived from each recovery code. These wrapped copies will be stored on the server. When you use a recovery code, the corresponding wrapped key will be decrypted locally to restore your encryption key.
After a recovery code is used, it will be permanently consumed — the corresponding hash and wrapped key blob will be removed from the server. If you are running low on recovery codes (2 or fewer remaining), Cliprift will prompt you to regenerate a fresh set.
Store your recovery codes safely
Recovery codes will be shown only once during setup. We recommend writing them down or saving them in a password manager. If you lose both your passphrase and all recovery codes, your encrypted data will not be recoverable — by anyone, including Cliprift.
E2E encryption will work seamlessly across all your devices. Because the encryption key is derived deterministically from your passphrase and salt, every device that knows your passphrase will derive the exact same key.
Enter your passphrase once per session. The key will be held in memory and cleared on sign-out. Encryption and decryption will happen via the Web Crypto API with no noticeable latency.
After pairing your device, you will enter your passphrase to derive the same key. The key will be stored in hardware-backed secure storage (Keychain on iOS, Keystore on Android). Biometric unlock will be available for subsequent sessions.
No key transfer needed. Unlike systems that require you to "export" or "share" a key file between devices, Cliprift will derive the same key on each device independently. The only thing shared will be the salt, which is stored on the server and is useless without your passphrase.
When E2E encryption is enabled, all clipboard content will be encrypted before it leaves your device. Here is what that will cover:
Every clipboard entry — plain text, HTML, and formatted content — will be encrypted before leaving your device.
Screenshots and copied images will be encrypted as binary data. Thumbnails and previews are generated locally.
Synced files will be encrypted end-to-end. File names and metadata will also be protected.
Content type, timestamps, and device origin will be encrypted alongside the payload. The server will store only opaque blobs.
Forward secrecy per item
Each clipboard item will be encrypted with a unique random initialization vector (IV). Even if two items have identical content, their encrypted forms will be completely different. This will prevent pattern analysis across your encrypted history.