StegoSafe: Threshold Key Storage in Ordinary Images

What this is

StegoSafe started in 2025 as a Python CLI experiment: encrypt a secret, split it with Shamir’s Secret Sharing, and store the shares inside ordinary image files so that no single image — and no single place — holds the whole thing.

It now ships as a native iOS and macOS app. This page keeps the original project write-up, because the reasoning still holds, and corrects the parts that time and a real product have since invalidated.

Updated 2026-09-23. The earlier version of this page described the CLI prototype as though it were the product, and repeated several claims I can no longer stand behind. Those corrections are listed at the bottom.

The problem it was built for

A seed phrase, a set of 2FA recovery codes, the master password to a password manager — these share an awkward property. They must never be lost, and they must never be read by anyone else. Those two requirements pull in opposite directions:

• Write it down once and it can burn, flood, or be found.
• Copy it for safety and you have multiplied the ways it leaks.
• Put it in the cloud and you have handed the problem to someone else’s breach notification.

Threshold cryptography is the honest answer to that tension. Split a secret into n shares such that any k of them reconstruct it and any k−1 reveal nothing. Lose two, recover anyway. Leak two, leak nothing. That is not a marketing claim; it is Shamir’s Secret Sharing, and it has a proof.

The steganographic part is a storage medium choice, not a security mechanism. It matters because photos are the one kind of file people already keep in many places, back up automatically, and never delete.

What the shipping app actually does

The app on the App Store is not the 2025 CLI. What it does today:

1. Encrypts on the device. The plaintext never leaves the phone or Mac, and there is no account and no server.
2. Optionally splits with Shamir, k-of-n, across separate images.
3. Writes the ciphertext into the pixels using sequential LSB replacement — roughly 0.375 bytes per pixel — and preserves the original image alongside.

It offers three protection modes, and the difference between them matters:

In the biometric mode the private key lives in the Secure Enclave, and Face ID or Touch ID is the local condition that releases it. No biometric data is held, transmitted or matched by any server — there is no server. One consequence worth knowing before you rely on it: re-enrolling Face ID or Touch ID on the device invalidates that key, and the original device key can no longer be used. That is the intended behaviour, and it is why anything meant for your family belongs in portable password mode instead.

It hides text, not files. At 0.375 bytes per pixel, a 12-megapixel photo carries a few megabytes in principle and a seed phrase in practice. It was never a file-transfer tool and is not becoming one.

What it does not claim

The earlier version of this page claimed detection resistance, anti-forensics, evasion of AI entropy scanning and quantum resistance. I am removing those rather than quietly softening them.

Sequential LSB replacement is not steganalysis-resistant. It is a well-understood embedding, and a chi-square or sample-pair analysis is a standard undergraduate exercise against it. Anyone claiming an LSB tool defeats statistical steganalysis is either using a different embedding or is wrong.

The security of this design rests on the encryption and the threshold scheme, not on whether an analyst can tell that an image carries something. Assume an adversary can detect it. The question that matters is what they get when they do, and the answer is ciphertext, plus — if you split it — an incomplete share of it.

That is a narrower claim than the old page made, and it is one I can defend.

The 2025 CLI

The original prototype is still on GitHub, and still works:

python stegosafe_cli.py embed -i test_images -s "your secret" -o output_images
python stegosafe_cli.py recover -i output_images

It embedded into EXIF metadata, which was the wrong call and is worth explaining, because the failure is instructive.

EXIF survives lossy recompression — the metadata block is not touched by JPEG quality settings, so a re-save loop leaves it intact. That looked like robustness. But EXIF is also the first thing every upload pipeline strips: it carries GPS coordinates and camera serial numbers, so Facebook, Instagram, Twitter and most CDNs remove it on principle. The prototype survived the hostile-sounding test (recompression) and failed the ordinary one (uploading the photo anywhere).

The shipping app moved to pixel data for exactly this reason. Pixels are what an image is; a platform that discards them has discarded the photo.

The sibling project: WaxSeal

The same line of work produced a second, different product, and the distinction is the interesting part.

StegoSafe stores. WaxSeal delivers.

StegoSafe’s image is a storage medium, so it can use a fragile embedding and simply not upload the file anywhere. WaxSeal’s image has to travel — through WhatsApp, WeChat, email, whatever the recipient uses — and arrive still readable. That is a completely different engineering problem, and LSB cannot solve it: the first recompression destroys it.

WaxSeal therefore uses a robust watermark — a neural encoder (TrustMark) with a dwtDctSvd fallback, plus Reed-Solomon error correction — which survives the compression and resizing that common chat platforms apply. It carries a short reference rather than the secret; the secret itself is encrypted for the recipients’ registered devices, and the vault holds ciphertext it cannot read. Because it opens only on an authorised device, a forwarded photo opens for nobody else, and the sender can expire, read-limit or revoke it afterwards.

The limit, stated plainly: revoking prevents further authorised opening. It cannot un-show what has already been read. No tool on either side of this can.

Corrections made on 2026-09-23

For the record, since this page was public and wrong:

• “Reed-Solomon” in the description and tags — StegoSafe splits with Shamir’s Secret Sharing. Reed-Solomon is WaxSeal’s watermark error correction, a different product.
• Detection-resistance and anti-forensics claims, including “evade AI-based entropy scanning” and passing chi-square and sample-pair analysis — removed. LSB does not survive standard steganalysis and the design does not depend on it doing so.
• “Quantum-resistant” — removed. AES-256 has a reasonable post-quantum story; nothing else here was designed against a quantum adversary, and the phrase was doing marketing work it had not earned.
• A performance table of timings and “detection resistance” ratings — removed. I cannot reproduce those numbers and do not believe they were measured.
• “Security Audit Results” and an “ongoing bug bounty program” — removed. No third-party audit was performed and no bounty programme exists.
• Covert-intelligence, spy and whistleblower use cases — removed. Recommending a tool that is not steganalysis-resistant to people whose safety depends on non-detection is irresponsible, whatever the tool’s other merits.
• A roadmap of HSM, post-quantum and audio-steganography milestones dated Q3 2025 through Q3 2026 — removed. None shipped; the effort went into the apps instead.
• www.stegosafe.com links, now a 301 — pointed at the apex domain.

Where it came from

My cybersecurity work at the University of the Fraser Valley under Professor Talia Q is what started this. His file-forensics material, and one ExifTool lecture in particular, is the direct ancestor of the EXIF prototype above — including, with hindsight, its mistake. His work is at Bohemian Digital and on YouTube.

Try it

• Apps: stegosafe.com — iOS and macOS
• Browser demo: stegosafe.com/demo
• 2025 CLI: github.com/harrison001/stegosafe-cli

Further reading

• Shamir’s Secret Sharing — the threshold scheme this is built on
• Steganography — the general technique, and its actual limits
• Exif — the metadata block the prototype used, and why upload pipelines strip it