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

Keeper is an embeddable secret store (Argon2id, XChaCha20-Poly1305 by default). Four security levels, audit chains, crash-safe rotation. Vault is overkill for most use cases. This is for when you ge paranoid about env and need encrypted local storage that doesn't suck. No security through obscurity, hence, It's still early, so now's the best time to find weird edge cases, race conditions, memory leaks, crypto misuse, anything that breaks. The README has a full security model breakdown if you want to get adversarial.

▲

Retr0id 43 minutes ago | parent | next [-]

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.

	▲	babawere 3 minutes ago \| parent [-]
		Thanks for the look. On the verification hash, you're right, SHA256 would work there. Argon2id was overkill, I agree 100%. The crash-safe WAL is the part I'm most nervous about too. That's exactly why I posted this. I want eyes on the rotation logic specifically. And yeah, single bbolt db is a limitation. I could have used pebble or any other, but trade-off for simplicity (a single *.db). A true WAL will need external file. The storage is pluggable though also open to improvement. Still very young.

▲

modelorona an hour ago | parent | prev | next [-]

Name could conflict with Keeper Security

	▲	babawere 14 minutes ago \| parent [-]
		So have been told. Will definitely look for a better name

▲

RALaBarge 41 minutes ago | parent | prev | next [-]

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!

▲

Retr0id 38 minutes ago | parent [-]

> The VerifyHMAC() function unconditionally returns true when the HMAC field is empty

This kind of thing is super common in vibecoded crypto, I wonder why it keeps happening.

	▲	RALaBarge 36 minutes ago \| parent \| next [-]
		Not sure, I've seen common things like this pop up a lot too, the same errors being tripped over. I'm not sure if it is a context thing or just a limitation of how the models work presently? For stuff that I'm using myself, I will run these through like the top 10 reasoning models on OR and just see where everything pans out. Edit: here is an example of the process and output with something I put together the other day: https://github.com/RALaBarge/garlicpress/blob/master/portfol...
	▲	babawere 23 minutes ago \| parent \| prev [-]
		Even when you have a proper function and use AI for auto documentation, it silently changes it (insane) … I will defiantly fix this.

▲

emanuele-em 44 minutes ago | parent | prev | next [-]

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.

	▲	babawere 22 minutes ago \| parent [-]
		I was thinking its better to be boring-correct :)

▲

n0n an hour ago | parent | prev | next [-]

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

	▲	babawere 20 minutes ago \| parent [-]
		not when you need an audit system

▲

elthor89 2 hours ago | parent | prev | next [-]

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?

	▲	babawere 15 minutes ago \| parent [-]
		Honestly… the initial use case is to hide certs from the file system and secrets from the environment. However, this can be extended. The primary issue has been not being able to manage an encrypted storage system… the main goal is to have something that can be audited, not just secured. yes 100% ... embeded

▲

tietjens an hour ago | parent | prev | next [-]

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

	▲	babawere 17 minutes ago \| parent [-]
		Definitely … agents cannot access your password unless you save it to the environment too. However it's better to use resolvers ... depending on your use case

▲

nonameiguess an hour ago | parent | prev [-]

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.

	▲	babawere 14 minutes ago \| parent [-]
		thanks for the update ... will definitely look for a better name