Security architecture
How iKrypt protects one-time encrypted secrets
iKrypt is designed around a simple trust boundary: encrypt the secret in your browser, store only ciphertext on the server, and keep the decryption key out of server requests.
Overview
Secret is encrypted in your browser
When you paste a password, API key, .env value, or credential, iKrypt encrypts it locally in your browser before anything is uploaded.
Server stores ciphertext only
The server receives encrypted ciphertext, an IV, expiry settings, and view-limit metadata. It never receives the plaintext secret.
Key stays in the URL fragment
The decryption key is placed after the # symbol in the link. Browsers do not send that fragment to servers in normal HTTP requests.
View limits are enforced server-side
When a secret is opened, iKrypt uses a Firestore transaction to reserve the view, update the view count, or delete the record on the final allowed view.
Browser-side encryption
When you paste a secret, iKrypt encrypts it in your browser using AES-256-GCM through the Web Crypto API. A fresh encryption key and random initialization vector are generated for each secret.
The plaintext secret is not sent to iKrypt. The server receives only encrypted ciphertext and the metadata needed to enforce expiry and view limits.
This makes iKrypt useful for quick handoffs such as passwords, API keys, .env values, temporary login credentials, and contractor/client access details.
The key stays after #
The decryption key is placed in the URL fragment, which is the part of the link after the # symbol.
In normal HTTP requests, browsers do not send the fragment to the server. iKrypt sees the secret ID, but not the decryption key.
What the server stores
Stores
- Encrypted ciphertext
- Initialization vector, also called IV
- Creation time
- Expiry time
- Current view count
- Maximum allowed views
Does not store
- Plaintext secret
- Decryption key
- Account profile
- Password vault data
Burn-after-reading is enforced on the server
View limits are not just UI behavior. The server checks and updates secret state inside a single transaction.
No plaintext on the server
Secrets are encrypted before upload, so iKrypt is not designed to store readable passwords, API keys, or credentials.
One-time access is atomic
View limits are enforced inside a transaction, avoiding the common race condition where simultaneous requests could consume the same one-view secret twice.
Expired secrets are blocked immediately
Once a secret expires, the API rejects access immediately, even if the encrypted database record has not yet been physically removed by TTL cleanup.
No analytics on secret pages
The pages where secrets are created or viewed do not load third-party analytics scripts.
Expiry and deletion
A secret becomes inaccessible immediately once it expires or reaches its view limit. The API rejects any further request as soon as either condition is true.
When the final allowed view is consumed, the encrypted record is deleted inside the same transaction that reserves that final view.
For secrets that expire without being viewed, encrypted records are removed by Firestore's TTL policy, typically within 24 hours of expiry.
Analytics and scripts
The pages where secrets are created or viewed do not load third-party analytics scripts. That keeps the most sensitive parts of the product cleaner and easier to reason about.
Some public marketing pages may use limited analytics to understand aggregate traffic. The details are listed in the privacy policy.
What iKrypt does not protect against
Browser-side encryption is useful, but it is not magic. It cannot protect against problems outside the encrypted handoff itself.
- A compromised sender or recipient device
- Malicious browser extensions that can read page content
- Someone forwarding the full link, including the key after #
- Screenshots, copy/paste, or manual saving after the secret is revealed
- A recipient intentionally sharing the revealed secret with someone else
Recommended usage
Treat iKrypt links as sensitive until they expire or are consumed.
- Share the full link only through a channel you trust.
- Treat the part after # as sensitive because it contains the decryption key.
- Use short expiry times for high-risk secrets.
- Prefer one-view links when the recipient only needs to read the secret once.
- Do not use iKrypt as long-term storage or a password manager.
Open source
Don't just trust the copy. Inspect the code.
Security tools should be inspectable. iKrypt's source code is public so developers can review how encryption, key handling, Firestore transactions, and expiry behavior are implemented.