[HN Gopher] Show HN: Keeper - embedded secret store for Go (help...
___________________________________________________________________
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.
Author : babawere
Score : 57 points
Date : 2026-04-10 08:53 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| elthor89 wrote:
| 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 wrote:
| 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
| n0n wrote:
| 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 wrote:
| not when you need an audit system
| n0n wrote:
| True, but AFAIK an audit system is worthless if it resides on
| the same potentially compromised machine, no?
| sneak wrote:
| https://git.eeqj.de/sneak/secret
|
| This is an age+filesystem secrets manager that I made that is
| basically what you wrote, but with more organization.
| modelorona wrote:
| Name could conflict with Keeper Security
| babawere wrote:
| So have been told. Will definitely look for a better name
| JoeBOFH wrote:
| Came to say the same thing lol. Especially since Keeper
| Security deal with credential management.
| nonameiguess wrote:
| 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 wrote:
| thanks for the update ... will definitely look for a better
| name
| tietjens wrote:
| Could I use this to store secrets to hide env vars from agents?
| babawere wrote:
| 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
| emanuele-em wrote:
| 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 wrote:
| I was thinking its better to be boring-correct :)
| emanuele-em wrote:
| yes I totally agree, my message was a compliment :)
| Retr0id wrote:
| 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 wrote:
| 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.
| RALaBarge wrote:
| 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 wrote:
| > 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 wrote:
| 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/RA
| LaBarge/garlicpress/blob/master/portfol...
| babawere wrote:
| Even when you have a proper function and use AI for auto
| documentation, it silently changes it (insane) ... I will
| defiantly fix this.
| babawere wrote:
| The first bug has been confirmed however The second
| `vulnerability` would only be exploitable if an attacker could
| also break SHA-256 preimage resistance to forge valid checksums
| ??? correct me if am wrong
| sneak wrote:
| 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
| babawere wrote:
| Thanks for sharing this. secret looks really well thought out,
| the three-layer key hierarchy is impressive. And using `age` is
| a solid choice. once considered it.
|
| Different trade-offs though, Keeper is library first embedded.
| secret does per version keys with symlink switching - nice,
| Keeper does per-bucket DEK isolation + audit chains. Both solve
| "encrypted local storage" but for different workflows.
|
| I'll definitely be looking through your code for ideas
| CharlesW wrote:
| 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.)
| babawere wrote:
| Both, honestly. Fun and production intent. But `production`
| here is very specific, embedded in a single Go binary, a single
| *.db not a CLI tool (the cli you see there is just for
| inspection) for developer or CI.
|
| The problem fnox solves is great, unified access to secrets
| across dev, CI, prod with cloud backends. That's a different
| layer of the stack.
|
| Keeper solves a lower-level problem: you have a Go process (a
| load balancer, a control plane, a daemon) that needs to store
| secrets inside its own database not in a separate file, not in
| a cloud vault, not in env vars. Secrets that need per bucket
| isolation, audit trails, and crash-safe rotation.
|
| Here is my thinking :
|
| - fnox = how your CLI and deploy scripts get secrets
|
| - Keeper = how your running binary stores secrets at rest
|
| Different problems, Could I build Keeper on top of fnox?
| Probably. But then I'd have a file on disk with secrets that
| fnox manages which is exactly the problem I wanted to
| eliminate.
| ComputerGuru wrote:
| 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
| blastslot wrote:
| That's actually a pretty interesting tradeoff -- especially
| going with "boring crypto" that's widely supported vs pulling
| in heavier deps.
|
| The JSON vault + cross-language portability is nice too,
| especially if you're embedding secrets across services without
| tying yourself to one runtime. Curious how you handle key
| management at scale though -- that's usually where these
| systems get tricky more than the crypto itself.
| ComputerGuru wrote:
| SecureStore is an open spec/protocol for managing secrets in
| a secure and portable manner, while it defines the decryption
| key formats (currently: key-based, password-based, or a mix
| of both interchangeably) it doesn't get into the mechanics of
| key management, which are "trivial and left as an exercise
| for the reader."
|
| More seriously though, you're supposed to use separate vaults
| (with the same keys, where "keys" is the name of the secrets,
| not the decryption keys) for testing/staging/production, e.g.
| perhaps secrets.{testing,production,staging}.json and the
| same secrets.{testing,production,staging}.key for the
| decryption keys, and store both the username and password in
| them (after all, it's just an encrypted, glorified KV store)
| so that you don't have to hard-code any usernames and
| conditionally load them based on the environment in your code
| (so db:username is one "secret" and db:password is another
| (actual) secret).
|
| The secrets vaults (the secrets.json files) are non-sensitive
| and can be versioned and pushed to your server the same way
| you push the binaries. Now how you move the secrets to the
| server is up to you. You could do it the old-fashioned way
| and just have it as an environment variable, in which case
| even when your env vars leak at least you haven't leaked your
| api keys, only the key to decrypt them (which you'd then
| rotate), but that's not a recommended option. Ideally you'd
| instead use whatever secure channel you use to init/stage the
| servers to begin with to transfer the secure key files - the
| key files are generally immutable, even as the secrets
| change, so you only have to do this once (ideally via a high-
| friction, high-auth mechanism, for most people not at FAANG
| scale, probably manually).
|
| You can also use whatever additional layer of abstraction on
| top of the symmetric SecureStore decryption key you like. For
| example, you could asymmetrically encrypt the keyfiles and
| then each host would decrypt it with its own private key, or
| have a secrets side channel that's just used to obtain the
| static decryption key over the local network, or use your
| operating system's encryption facilities to transmit it,
| whatever works for you at whatever point on the
| complexity/security curve you desire.
|
| (These are all just options, none are official
| recommendations.)
| cifer_security wrote:
| 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?
| Retr0id wrote:
| I know I'm responding to an LLM but in the interest of not
| polluting the dataset further I'll point out that all the
| primitives used here are already post-quantum secure.
___________________________________________________________________
(page generated 2026-04-10 23:01 UTC)