- 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.
- 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.
by nonameiguess
1 subcomments
- 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.
by modelorona
2 subcomments
- Name could conflict with Keeper Security
by ComputerGuru
1 subcomments
- 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.)
- 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?
by emanuele-em
1 subcomments
- 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 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
- 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
- Could I use this to store secrets to hide env vars from agents?
by cifer_security
1 subcomments
- 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?
by RALaBarge
2 subcomments
- 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!
by takahitoyoneda
0 subcomment
- [dead]
by fedorsapronov
0 subcomment
- [dead]
Hacker News