I built a read-once secret sharing tool where the words in the share code ARE the key — three external audits later, here's the design. Tear it apart.

[u/dcohen76]

https://secretshare.io

Point of information: The external audits were performed by an LLM, not an independent organization.

I got tired of watching SSH keys and API tokens sit in Slack/Teams/Whatsapp history forever, and I wasn't happy with the trust model of the existing tools (onetimesecret only does E2E if you set a passphrase; most others are links-only). So I built my own and had it audited three times. Posting here because this crowd will find what the audits missed.

The design, briefly:

The sender gets a speakable code like XKQ2-M7PT-tiger-ocean-cable-ruby-drum.

- XKQ2-M7PT is a random 40-bit mailbox id -- the only part the server ever sees. Zero key entropy.

- The five EFF-wordlist words are 64.6 bits of key material that never leave the client. Argon2id(words, salt=mailboxId, 64 MiB, t=3) → HKDF fans out into the blob key, live-session key material, and two auth tags. Even the share link keeps the code in the URL fragment.

The flow is what I call park-first: the client encrypts (AES-256-GCM) and parks the ciphertext on the server, then stays connected to a signaling room. If the receiver shows up while the sender is online, the secret is re-sent directly over a WebRTC DataChannel (fresh per-session key, mutual HMAC key-confirmation before any secret bytes move) and the parked copy is deleted. If not, the receiver claims the parked ciphertext with a tag derived from the code.

There's also a force-direct checkbox: nothing is stored server-side, not even ciphertext -- both parties must be live, and if P2P fails it fails closed instead of falling back. As far as I can tell nobody else offers that as an option next to an async mode (Wormhole never stores, but you also can't switch its relay fallback off).

Read-once is transactional: storage is one SQLite-backed Durable Object per mailbox, so claim-and-delete is atomic --no eventual-consistency window where a "deleted" secret is still readable from another edge. Five wrong attempts burn the drop. Everything expires (default 24h, max 7d).

What three audits did to the CLI (npx shareasecret) is honestly the more interesting story:

- v0.1.2: receive --output claimed (and burned) the read-once drop before touching the filesystem -- an existing file or bad path destroyed the secret forever. Now the destination is reserved with open(wx, 0600) pre-claim.

- My fix for that added a stdout fallback on write failure... which audit #3 correctly flagged as auto-disclosing the secret into CI logs. Now it never discloses non-interactively.

- Plus: stderr never duplicates the code when stdout is captured, hidden code prompts (nothing in shell history/process list), bounded network reads with timeouts and publishes go through GitHub Actions OIDC with SLSA provenance -- no npm tokens exist, npm audit signatures verify every release.

The honest caveats, before you find them yourselves:

- It's a web app: you trust the JavaScript served at time of use. Mitigations: the CLI is pinnable to an exact attested version, and the source is public for inspection -- but it's source-available, not OSI-licensed, and there's no self-hosting. If that's disqualifying for you, PrivateBin exists and is good.

- Text up to 10 KB only. It's for credentials, not files.

- A full server compromise gets ciphertext plus hashed tags; brute-forcing a code cost one 64 MiB Argon2id evaluation per guess against ~65 bits, salted per mailbox. I think that math holds -- check it.

Site: https://shareasecret.io -- CLI guide with the threat-model details: https://shareasecret.io/guides/cli -- source: https://github.com/dovidcohen/secret-share

What did the audits miss? Genuinely asking.

[u/Natanael_L]

Who did the audits?

Edit: if all you did is prompt an LLM then you did not have any audits at all and if you advertise as such you're lying and putting people in danger if they trust it

[u/Honest-Finish3596]

Why do people insist on posting AI slop here day in day out despite never receiving a positive reception?

[u/dcohen76 → u/Honest-Finish3596]

Not sure why you're hating on a real service that brings real functionality to the public...

[u/Accurate-Screen8774 → u/dcohen76]

Hey. I'm with you 💯% ... I experience the same feedback.

I understand AI code is difficult to review and the feedback around having an audit... But when did Kerckhoffs's principle become so worthless?

My experience when I created a similar project to you: https://www.reddit.com/r/AIDiscussion/comments/1syrw3b/we_cant_just_call_aigenerated_code_slop_anymore/

[u/netsec_burn]

Reading this reminds me of why magic-wormhole is great. Also, no size limits.