HN Explorer

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

64 points by babawere ↗ HN
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.

16 comments

[ 3.0 ms ] story [ 41.0 ms ] thread
elthor89
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?

n0n
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

modelorona
Name could conflict with Keeper Security
nonameiguess
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.

tietjens
Could I use this to store secrets to hide env vars from agents?
emanuele-em
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.
Retr0id
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.

CharlesW
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.)
ComputerGuru
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

cifer_security
A few thoughts on the WAL approach: WAL for crash-safe rotation is tricky — if the write isn't atomic, you can end up in a corrupt state on crash. An append-only log might be safer. For "paranoid env" use cases, have you looked at post-quantum KEMs? ML-KEM is now NIST standardized and has better forward secrecy properties against quantum adversaries. What's your threat model for the WAL feature?
guyle
Interesting approach for embedded use cases. Curious how you see this compared to the OIDC trend in CI/CD where the goal is eliminating stored secrets entirely — different problem space but related threat model.