stasher-dev (u/stasher-dev)

stasher-dev commented on Show HN: SecretShare – Easy, secure one time secret sharing CLI · Posted by u/scosman

stasher-dev · 17 days ago

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.

stasher-dev commented on Show HN: Stasher – Burn-after-read secrets from the CLI, no server, no trust github.com/stasher-dev/st... · Posted by u/stasher-dev

coldstartops · 19 days ago

You built it because you wanted to share passwords:

And your flow is: I encrypt my password; I upload the encrypted password to your server.

And I share the password to the encrypted password as plain text.

Why do I have to upload the encrypted password to your server, and not just use signal disapearing messages, or telegram secure channel disappearing messages to share the encrypted password there.

And I can use any other side channel to share the second password, like whatsapp, or regular plain mail.

It feels to me that you made a two step process into a one step process but increased the risk by adding you in the middle.

Why would I offload my trust to you instead of doing the second step?

stasher-dev · 19 days ago

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.

stasher-dev commented on Show HN: Stasher – Burn-after-read secrets from the CLI, no server, no trust github.com/stasher-dev/st... · Posted by u/stasher-dev

arp242 · 19 days ago

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.

stasher-dev · 19 days ago

Thanks for your feedback 'I tried to use of the shelf stuff for the crypto and utilised what I believe to be battle tested.

CLI uses node.js built-in crypto module only -randomBytes - createDecipheriv - createCipheriv.

Web app uses Web Crypto API only.

I'll send Filippo a Postcard and see if he will review it :-P

stasher-dev commented on Show HN: Stasher – Burn-after-read secrets from the CLI, no server, no trust github.com/stasher-dev/st... · Posted by u/stasher-dev

JCBird1012 · 19 days ago

I'd recommend changing your tagline -

> Share secrets from your terminal. One-time only. No accounts. No backend. No BS.

A server sure sounds like a backend to me.

stasher-dev · 19 days ago

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

stasher-dev commented on Show HN: Stasher – Burn-after-read secrets from the CLI, no server, no trust github.com/stasher-dev/st... · Posted by u/stasher-dev

h43z · 19 days ago

Do I understand this correctly that the server here is only needed to make sure the secret it's only read once?

stasher-dev · 19 days ago

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

stasher-dev commented on Show HN: Stasher – Burn-after-read secrets from the CLI, no server, no trust github.com/stasher-dev/st... · Posted by u/stasher-dev

i_am_proteus · 19 days ago

Why use this instead of GPG?

stasher-dev · 19 days ago

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.

stasher-dev commented on Show HN: Stasher – Burn-after-read secrets from the CLI, no server, no trust github.com/stasher-dev/st... · Posted by u/stasher-dev

i_am_proteus · 19 days ago

Would you please elaborate on how "the releases are signed" helps establish trust in the context of your anonymous developer account?

stasher-dev · 19 days ago

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.

stasher-dev commented on Show HN: Stasher – Burn-after-read secrets from the CLI, no server, no trust github.com/stasher-dev/st... · Posted by u/stasher-dev

cess11 · 19 days ago

So the ten minute thing is a trust issue. How are salts handled?

stasher-dev · 19 days ago

So the ten minute thing is a trust issue?

Stasher enforces expiry in two layers:

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)

stasher-dev commented on Show HN: Stasher – Burn-after-read secrets from the CLI, no server, no trust github.com/stasher-dev/st... · Posted by u/stasher-dev

mbreese · 19 days ago

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.

But maybe that’s just me.

stasher-dev · 19 days ago

I get it. An 'anonymous' author is a deal breaker for some. I respect that.

The repo is public. The releases are signed. The attestations are published. Nothing hidden.

If that’s not enough — totally fair and I am sure many others would agree. Appreciate your point of view and taking time to give feedback.

stasher-dev commented on Show HN: Stasher – Burn-after-read secrets from the CLI, no server, no trust github.com/stasher-dev/st... · Posted by u/stasher-dev

masfuerte · 19 days ago

I feel like I'm being very stupid. If the key never leaves my machine, how do I share a secret?

stasher-dev · 19 days ago

When you run:

npx enstash "my secret"

Stasher performs everything locally:

Generates a random 256-bit encryption key

Encrypts your secret using AES-256-GCM

Sends only:

the ciphertext

the IV (initialization vector)

the auth tag

a randomly generated UUID

The encryption key is never sent to the server. It never leaves your machine.

You are then shown a single string:

uuid:base64key

The uuid points to the encrypted stash on the server

The base64key is the encryption key you just generated

Only the person who has both parts can decrypt the secret

How You Share the Secret

You send the full uuid:base64key token to your recipient — over any channel you like slack or whatever.

When they run:

npx destash "uuid:base64key" on the token

Stasher:

Fetches the encrypted stash using the uuid

Deletes it immediately (burn-after-read)

Decrypts it locally using the base64key

Shows the secret

The server never sees the key. Not during upload or during retrieval.