Show HN: Keeper – embedded secret store for Go (help me break it)

Mmmm vibecrypto, my favourite. I don't see anything obviously broken (at a glance) but as a perf improvement, there's little reason to use Argon2id for the "verification hash" step, might as well use sha256 there. There is also no need to use ConstantTimeCompare because the value being compared against is not secret, although it doesn't hurt.

The "Crash-safe rotation WAL" feature sounds sketchy and it's what I'd audit closely, if I was auditing closely.

We actually just ported SecureStore to go, it’s sort of like this but with cross platform clis and intended to also allow sharing secrets across services and languages, in a secure and embedded fashion! It’s available in rust, php, .net, JS/TS, Python, and golang and easy to port to others.

I didn’t get a chance to do a write up but the golang port is here: https://github.com/neosmart/securestore-go

The approach to crypto is very different, we went with what’s very well understood and very well supported on all platforms with little or no dependencies (eg we can use web crypto in JS frontend or backend with no external libs or crypto JS library nonsense).

The original .NET and Rust code is from over a decade ago and carefully architected (well before vibecoding was a thing), the secrets are stored in a human readable (json) vault that can be embedded in your binaries or distributed alongside them and be decrypted with either password-based or key-based decryption (or both).

The rust repo has the most info: https://github.com/neosmart/securestore-rs

From a project perspective, is this for fun or is it meant to be a production solution? If the latter, what problem(s) are you trying to solve that established solutions like fnox don't? https://github.com/jdx/fnox (I'm an fnox user who's unfamiliar with this space, and am curious what your critiques would be.)

Name could conflict with Keeper Security

Per-bucket DEKs with HKDF, hashed policy keys to kill enumeration, HMAC audit chain. This is the kind of boring-correct crypto design I rarely see in Go libraries. memguard for the master key is a nice touch too.

I have been looking for something like this. I know openbao, hashicorp vault.

But they require to be placed on a separate server, and come with their own infra management.

Is the idea of this project to embed this into you app, instead of relying on .env or an external vault?

Could I use this to store secrets to hide env vars from agents?

Genuine question: what's your thread model?

Vault gives time limited Tokens with Network Boundary. Instead of Keeper, i would just use age:

# write

echo "my secret" | age -r <recipient-pubkey> > secret.age

# read

age -d -i key.txt secret.age

Hey I ran this request through my AI harness (beigeboxoss.com), first with a smaller local model and then validated with Trinity Large via OR. https://github.com/agberohq/keeper/issues/2 -- YMMV but wanted something to do with my coffee, thanks!

Keeper is already the name of a popular enterprise secrets store: https://docs.keeper.io/en/user-guides/web-vault

I haven't used it, don't advocate for it, and have no opinion on either its viability or your product's viability for any specific use case. Mostly I just think it's a bit confusing to have two separate products in a very similar space with the same name.

I have a similar one called “secret”, also in Go, that is more CLI-focused and uses the filesystem as database.

https://git.eeqj.de/sneak/secret

[dead]

[dead]