WaxSeal: Robust Image Watermarking for Secret Delivery
Delivering a secret through chat apps that recompress every photo. Why LSB cannot survive the trip, what a robust watermark costs, and the measurements behind a two-tier design.
WaxSeal: Robust Image Watermarking for Secret Delivery
The problem
You need to hand a credential to a named colleague. Not publish it, not store it — hand it over, through whatever channel they actually use, and keep the ability to stop it being opened again later.
Every obvious answer has a hole in it. Email and chat leave a permanent copy in two mailboxes. A one-time link can be spent by a link preview or a mail scanner before the recipient ever clicks. A password-protected file needs the password sent through the same broken channel.
The approach here is to make the carrier an ordinary photo — something every channel already accepts, nobody inspects, and a recipient can forward without the secret travelling with it. That decision creates an engineering problem which turns out to be the interesting part.
Why the photo is the hard part
Send a photo the normal way on any major platform and it does not arrive as you sent it. It arrives resized and re-encoded as a fresh JPEG, server-side, whether you like it or not.
That destroys ordinary steganography completely. Least-significant-bit embedding — the method every tutorial teaches, and the one StegoSafe uses for storage, where the file is never uploaded anywhere — puts the payload in exactly the bits a re-encode overwrites.
Measured, over twelve simulated channels at ten trials each:
| Method | Recompression | Rescale |
|---|---|---|
| Sequential LSB | 0/10 — ~49% BER, a coin flip | 0/10 |
| dwtDctSvd, raw | partial — dies below quality 70 | 0/10 |
| dwtDctSvd + RS(32,8) | 10/10 | 0/10 |
| Learned mark (TrustMark) | 10/10 | 10/10 |
Three findings worth keeping:
LSB is erased, not degraded. A ~50% bit error rate is a coin flip per bit — there is no information left, and no error-correcting code recovers from it. Even JPEG quality 90 with no resize at all is total loss.
Reed-Solomon is what makes the classic tier viable. A raw transform-domain mark comes back from a simulated WhatsApp send at 3.2% BER and still scores 0/10 on exact recovery, because a key reference has to be exactly right. Wrapping the same payload in RS(32,8) takes it to 10/10. One counter-intuitive detail: do not interleave the bits. The channel’s errors arrive in bursts that fall inside a byte, and Reed-Solomon is a symbol code, so a byte with eight bad bits costs the same as a byte with one — interleaving would smear cheap concentrated failures across many symbols.
Rescaling is a different failure, and parity cannot touch it. A transform-domain mark is read from coefficients at known positions; rescale and every position moves, so the decoder reads the wrong places. The mark survives lossy quality-50 JPEG and dies on a lossless rescale. Clearing that needs geometric robustness by construction — a learned encoder trained with resizing in its augmentations.
Hence two tiers: the learned mark as primary, dwtDctSvd + Reed-Solomon as fallback. The reason to keep the fallback is not image quality — the learned mark measured better on PSNR, 40.7 dB against 39.1 dB — but that it drags in torch, hundreds of megabytes of dependencies and model weights, which on a phone is a binary-size and battery question.
The full write-up, with every table and a self-contained script that reproduces it, is in Why Hidden Data Dies in Chat Apps.
What the mark actually carries
Not the secret. The photo carries a short sealed reference and nothing else, so intercepting the image yields nothing to decrypt.
The secret is encrypted for the recipients’ registered devices. Each approved device’s private key is generated inside Apple’s Secure Enclave and never leaves it; the content key is wrapped to each device’s own public key (HPKE, RFC 9180). The vault stores ciphertext and opaque wrapped keys and cannot read any of it.
Face ID or Touch ID is the local condition that releases the device’s key, on that device. No biometric is held, transmitted or matched by any server — the protocol registers device public keys, not faces.
The practical consequence is that a forwarded photo opens for nobody else, because authorisation is bound to a device rather than to a password that can be passed along or a link anyone can follow.
What it does not do
Worth stating plainly, because the shorter version would be false:
- Revoking, expiring and read-limiting stop future authorised opens. They cannot un-show what a recipient has already opened and screenshotted. No tool on either side of this can.
- The guarantee is scoped to compression and resizing — what platforms actually do to a photo in normal use. Crop it, screenshot it and re-share the screenshot, or paint over it, and you are past what any photo-borne mark can carry.
- An interceptor sees a photo and some metadata. No plaintext — but they can see that a photo was sent.
- This is not an anti-detection tool. A robust watermark is more statistically conspicuous than LSB, not less. If your requirement is that nobody can tell the image carries anything, this does not address it.
- It carries text, not files. A password, a key, a bank detail — not a contract.
Related
- StegoSafe — the storage side of the same problem, and why its answer is the opposite one.
- Why Hidden Data Dies in Chat Apps — the full measurements, reproducible.
Comments
This space is waiting for your voice.
Comments will be supported shortly. Stay connected for updates!
This section will display user comments from various platforms like X, Reddit, YouTube, and more. Comments will be curated for quality and relevance.
Have questions? Reach out through:
Want to see your comment featured? Mention us on X or tag us on Reddit.