What is an encrypted file link?
It is a URL that lets the holder download a file that was encrypted in the sender's browser. The stored copy is ciphertext only. The decryption key sits after the # and never reaches the storage service.
AVAILABLE FOR DEVOPS & SYSTEM ENGINEERING · COLOMBO / KANDY · REMOTE / HYBRID · AVAILABLE FOR FREELANCE PROJECTS
DEVOPS UTILITIES / ALL TOOLS
EncryFy
Send a file of up to 100 MB as an encrypted link. The file is encrypted in your browser, only ciphertext is stored, and the decryption key stays in the URL fragment.
ZERO-KNOWLEDGE DESIGN
How the Encryption Works
When you create a link, this page generates a fresh 256-bit AES-GCM key and a random 12-byte initialization vector, packs the file name and bytes into a binary envelope, and encrypts that envelope with the Web Crypto API. The key is exported separately and appended to the link after a #, so the finished URL carries the key while the request that stores the ciphertext does not.
Nothing is reused between files. Every link has its own key and its own initialization vector, so recovering one file tells an attacker nothing about any other.
DATA BOUNDARY
What the Service Receives
Without the key, stored bytes are not decryptable by the operator, by anyone who compromises the volume, or by anyone served a copy of the ciphertext.
| Value | Sent to the service | Reason |
|---|---|---|
| The file bytes and name | Never | They are encrypted in this browser before any request is made. |
| The encryption key | Never | It is placed after the # in the link, and browsers do not send fragments to servers. |
| The ciphertext | Yes | Stored as opaque bytes on a volume-mounted path the service has no key for. |
| The file identifier | Yes | A random handle used to look the record up. |
WHY THE HASH MATTERS
Why the Key Sits After the #
Everything after the # in a URL is the fragment. It is a client-side addressing feature, and browsers strip it before building the HTTP request, so it never appears in a request line, a proxy log, an access log, or a referrer header.
If a chat client or copy-and-paste drops the part after the #, the ciphertext may still exist later but no key does, and no one can recover the file.
INTENDED STORAGE
Where Ciphertext Will Live
Encrypted files sit on a local-path volume mounted into the file-sharing container on Contabo K3s at api.gajan.dev. That is a durable store for opaque bytes, not a place the operator can read filenames or contents.
There is no expiry yet. An abandoned link keeps working until the ciphertext is deleted from the volume by hand.
SIZE AND HONEST LIMITS
What This Does Not Protect Against
The maximum file size is 100 MB. Encryption in the browser removes one specific risk, which is the storage service reading your file. It does not remove the rest:
- A compromised endpoint. If either machine has malware or a hostile browser extension, the plaintext is readable at the moment it is chosen or downloaded.
- Whoever holds the link holds the file. There is no identity check. The link is the credential.
- The recipient after they download it. They can copy, forward, or keep the decrypted file. Reusable links do not expire on first download.
- The channel you use to send the link. Sending it over the same compromised channel you were trying to avoid gains you very little.
- Availability. This is homelab infrastructure. Treat it as a convenience, not as something to depend on during an incident.
FREQUENTLY ASKED QUESTIONS
EncryFy FAQ
Can the server read my file?
No. The file name and bytes are encrypted in your browser with AES-GCM before upload, and the key is never transmitted. The service holds ciphertext it has no key for.
Why is the decryption key after the # in the link?
Everything after the # is the URL fragment. Browsers keep fragments local and never place them in the HTTP request, so the key can travel inside the link without ever reaching the service that stores the ciphertext.
Is this a one-time download?
No. Unlike one-time secret sharing, this link is reusable. Anyone who has the complete URL can download the file until a later retention policy removes it.
Who pays to share a file?
The sender pays a one-time Dialog, Hutch, or Airtel mobile charge through Ideamart CaaS before the ciphertext is stored. The charge runs on the Contabo API, not in this browser. Anyone with the full link can still download for free.
How large can the file be?
One file of up to 100 MB. Larger files are rejected in the browser before encryption starts.
Where will the ciphertext live?
On a volume-mounted path inside the file-sharing container on Contabo K3s, as opaque encrypted bytes. The operator cannot read filenames or contents without the key in the URL fragment.
What happens if the link is truncated when it is pasted?
The fragment is the key, so a link cut short after the # is unrecoverable. There is no copy of the key anywhere else. Create a new share and send the complete link.
Is this a replacement for a file host or backup?
No. It is a way to hand one encrypted file to people who have the link. It is not a drive, a sync client, or an archive.