Encryption
How Collogue Encrypts a Private Message
A concise explanation of the verified browser-side encryption flow used by Collogue.
Published: February 17, 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
This idea is simple. Implementing it correctly is where the interesting problems begin.
A message begins as readable text inside the sender’s browser.
- the user;
- the browser;
- page scripts;
- browser extensions with sufficient access;
- malware on the device;
- accessibility and input systems.
This is not a defect unique to Collogue. A secret must exist somewhere in readable form before it can be encrypted.
A cryptographic key should come from a cryptographically secure source or a documented derivation process. Human-looking randomness is not enough. A timestamp with decorative punctuation is still a timestamp.
If a passphrase is involved, the implementation must use an appropriate key-derivation function and parameters. If a random key is generated, its length and generation source should be documented.
- Confidentiality — the ciphertext does not reveal the plaintext without the key.
- Integrity — unauthorized modification is detected during decryption.
The public page should name the exact construction only after code verification. “AES” alone is not a complete description. Modes, nonces, authentication tags, key sizes, encoding, and error handling matter.
Cryptographic APIs are famously willing to provide sharp tools with professionally machined handles. Correct usage is part of the design.
The expected safe shape, if supported by the actual code, is a request containing ciphertext and operational settings rather than readable message text.
Inspect the browser network panel. Do not infer this property from UI copy.
These values are not automatically secret. Some are required for decryption and can safely accompany the ciphertext. The key is the critical distinction.
A secure link is not necessarily harmless metadata. If possession of the full link enables decryption, the link is a bearer capability: whoever has it may be able to open the message.
That means the link should be treated with roughly the same care as the secret during its short lifetime.
This detail matters because automated systems may request links. A plain GET request is easier for a preview bot to trigger than an explicit human action, though no mechanism perfectly proves humanity.
The recipient’s browser obtains the ciphertext and the required key material, then performs authenticated decryption.
If authentication fails, the application should report that the message could not be verified or decrypted. It should not display corrupted text as though nothing happened.
Successful decryption creates plaintext in the recipient’s browser. From that point onward, cryptography cannot prevent copying, screenshots, photography, or an infected device from capturing the message.
The encryption protects a journey. It cannot govern the recipient’s future.
A strong privacy page names the boundary instead of replacing it with “gone forever.”
The right conclusion is not pessimism. It is specificity.
Collogue should make a limited promise, support it with observable behavior, and explain the assumptions. That is more useful than attaching a large lock icon to a small paragraph.
No. Secure key generation, authenticated encryption, unique nonces where required, correct encoding, integrity checks, and safe error handling are all part of the protocol.
Because decryption must produce readable text on the recipient’s device. Cryptography can control access before that moment, not the recipient’s behavior afterward.
Create a private Collogue link when you need to send a password, token, recovery code, or another short piece of sensitive text.