Encryption keys
Where Is the Decryption Key?
Why Collogue uses a separately entered password rather than putting the key in the URL.
Published: February 28, 2026
Current implementation boundary
Current Collogue links carry the encrypted payload in the URL. The browser uses Web Crypto API: PBKDF2-SHA-256 with 310,000 iterations derives a 256-bit AES-GCM key from the separately entered password, with a random 16-byte salt and a 12-byte IV. The current client has no application API request for creating, retrieving, or storing messages.
The password is not encoded in the link. The implementation does not provide one-time viewing, server-side deletion, or an expiry timer. Treat the full link as sensitive and share the password through a separate channel.
Further context
Encryption replaces one difficult problem with another.
Keys are small. Their consequences are not.
A symmetric encryption key allows the recipient’s browser to transform authenticated ciphertext back into plaintext.
``text https://collogue.net/m/example-message#example-key-material ``
Use that example only if it matches the actual architecture.
The fragment is the part of a URL after #.
``text https://example.test/message/123#key-material ``
``text /message/123 ``
The browser retains #key-material locally and makes it available to the loaded page.
But three cautions matter.
First, the JavaScript loaded by the page can read the fragment. Browser-side decryption requires this or an equivalent mechanism.
Second, the full link is now a capability. Anyone who obtains it may receive both the ciphertext reference and the key.
Third, fragments can still leak through human behavior, screenshots, copied text, browser extensions, clipboard history, synchronization tools, or altered client code.
A fragment is a useful protocol boundary. It is not a force field.
- access logs;
- reverse-proxy logs;
- browser history;
- copied diagnostics;
- referrer data, depending on policy and navigation;
- monitoring systems.
In that case, the public article must explain the real exposure rather than describing fragment behavior.
A memorable passphrase and a uniformly random key are not interchangeable. Derivation parameters matter.
Users sometimes assume that an encrypted link is safe to post publicly because it “only contains encrypted data.”
That conclusion is wrong when the link also supplies the capability to decrypt.
- public issue trackers;
- shared channels with unnecessary members;
- URL-analysis services;
- public link shorteners;
- documents with broad access.
Possession of the link may demonstrate possession of the link. It does not necessarily establish identity.
If an attacker obtains the URL before the intended recipient, the cryptography may work perfectly for the attacker.
This is the recurring lesson of bearer capabilities: authorization is represented by possession.
For higher-risk secrets, verify the recipient and consider a separate channel for context or additional authentication. Do not describe separate channels as automatically secure; they merely change the attack requirements.
- the sender sharing the wrong link;
- the recipient forwarding it;
- browser malware reading the fragment;
- a malicious page script capturing plaintext;
- clipboard history retaining the URL;
- a link scanner requesting the page;
- the recipient saving the decrypted message.
It can be a useful design because the fragment is normally not sent in HTTP requests. Safety still depends on the delivered page, browser environment, link handling, and recipient behavior.
Yes. JavaScript running on the page can access the fragment. That is commonly how client-side decryption obtains key material.
If Collogue does not retain or derive the key, losing the required link material may make the message unrecoverable. Confirm the implementation before publishing that statement.
Create a private Collogue link when you need to send a password, token, recovery code, or another short piece of sensitive text.