Nice one! I was the author of the original post and got roasted. Lol
Even if no one uses my project as a result of this guys work. I am pleased it's generated a safer outcome for everyone and from a more trustworthy source.
I liked the idea a lot! But yeah, saying no-servers when there are servers will get ya roasted here. You got me thinking about this and it was fun to whip up.
Your skepticism is valid and if your flow already includes: A secure messaging tool (e.g. Signal), a GPG workflow or local encryption or a team that uses shared password vaults. Then to be fair Stasher might not be better.
I built Stasher for me. I wanted an easy, CLI-first way to share one-time secrets without worrying about accounts, apps, or trust. If Signal or GPG works better for you that’s totally cool.
Stasher exists to make casual, secure sharing simpler not to replace tools you already trust.
Yes, you are understanding it correctly, the server (Cloudflare Worker + Durable Object + KV) in Stasher is only needed to enforce the burn-after-read behaviour
zero setup, burn after read, no key exchange required, GPG is ideal for persistent trust relationships (e.g., signing emails), Stasher is purpose-built for temporary relationships. To me GPG is overkill for sharing simple shares. Defo not trying to replace GPG, just a different use case.
Thanks for raising these concerns — totally fair in the context of security tools.
I’m not anonymous, just cautious. I’m a solo builder, and this is a focused identity for the project. In fact, that's why I implemented full supply chain transparency from day one: signed releases, SLSA attestations, SBOMs, and Rekor logs. You don't need to trust me you can see the code for your self.
Ultimately, you're right — if you can't verify it, you shouldn't trust it.
That’s the whole point of the system: zero trust and verifiable cryptographic guarantees.
A "focused identity" with no links to other identities is anonymous by definition.
More importantly, this project is not "zero trust" and calling it such is borderline deceptive.
I can verify the artifacts you're shipping contain the code in the repo (or I could just clone the repo myself), but I cannot automatically verify that your code is non-malicious and free of bugs. That is what I am trusting when using your software, and I have serious doubts about the "free of bugs" part for AI generated software.
I’m right there with you in mistrusting AI generated code but - you also can’t automatically verify that human-written code is non-malicious and bug free.
Cryptography/security is a trust business. Without some kind of personal (or even project) history, I know nothing about you or the project. And if I can’t verify you, I can’t trust you. The rest doesn’t matter much to me.
It means the releases are cryptographically signed using GitHub OIDC, with SLSA v1 provenance and entries in the Rekor transparency log.
That means:You can verify every artifact against its source code i.e I have not tampered with the code post deployment. for example part of the build is a dry-run on the worker build, this is stored as part of the build so you can see / confirm the exact code that was uploaded and this code is signed.
What people mean with "trust" here is whether they trust there are no subtle security issues. While I think "don't roll your crypto" has been somewhat overstated at times (someone has to write crypto), there is certainly some truth in that you need to be very careful writing this code and that mistakes are incredibly easy to make, even for competent developers.
If I were to release something like this then people can see that 1) this is a guy with >20 years of various contributions to open source and he seems like a basically competent guy we can trust (as much as you can ever trust a single person), but also that 2) he's not a crypto guy and there may very well be oversights. Maybe there are none, but you know...
If someone like, say, Filippo Valsorda would release someone like this, then people could see that 1) is basically the same as me, and 2) he's also a well known crypto guy with a good track record. This is not a guarantee there are no oversights, but I would certainly be surprised if there were major ones. I would certainly trust that more than anything I would write.
The whole signing stuff is kind of a red herring IMO. I mean, it's not bad to have I guess, but honestly I don't really care. If anything, focusing to strongly on "box ticking security" so early on seems like the wrong thing to focus on.
Humans also use em dashes — like that. My browser for one automatically creates them on HN if you correctly type a space, two hyphens then another space. Maybe the dude just has good grammar.
We'll find out in an hour, but I bet openai trained em-dashes out of gpt-5 and that will confuse a lot of people. At least you'll be able to write the way you want to...
Yes I do — and that’s not an em dash, it’s two hyphens. You’re not using a manual typewriter, you have Unicode. You don’t make an exclamation point from an apostrophe and a period, do you?
Hey. Only the ciphertext is stored on the server; the key never leaves your machine. The uuid:key format is just a pointer to the encrypted payload. Without the key, the server’s stash is useless. Zero-knowledge by design
Reactive expiry — When someone tries to retrieve a stash (destash), the Durable Object checks the creation timestamp before serving. If it's older than 10 minutes, it refuses the request.
Proactive cleanup — Every stash’s Durable Object sets a scheduled alarm to self-destruct after 10 minutes. This removes the coordinating DO and ensures the encrypted blob in KV expires (via TTL).
So even if someone tries to cheat the system, or access after the 10-minute window, they’ll get an error — the stash is gone.
This is part of what makes it “burn-after-read, or expire-after-time”. No guessing, no timers in memory or cron job workers.
How are salts handled?
Stasher uses AES-256-GCM, which does not require a traditional salt like in password hashing (e.g. PBKDF2, bcrypt). Instead, it uses an IV (initialization vector).
With a fresh 96-bit IV is generated for every encryption
AES-GCM uses that IV as part of the encryption process, ensuring non-deterministic ciphertext. The IV is not secret, and is uploaded alongside the ciphertext and GCM tag
On decryption, the IV is used to reconstruct the exact same cipher context
So in short: No static salts and no reused IVs
Everything you need to decrypt is bundled with the encrypted stash, except the key, which stays with the user (as part of the uuid:base64key token)
Yes, that's a fair comment technically speaking: Cloudflare Workers + KV + Durable Objects is a backend. I was trying to imply No user accounts, no persistent database, no stateful sessions etc I will reword - thanks for the feedback
Even if no one uses my project as a result of this guys work. I am pleased it's generated a safer outcome for everyone and from a more trustworthy source.