Hi HN,
I built AxKeyStore, an open-source CLI tool for managing secrets that uses your own private GitHub repository as encrypted storage.
The idea is simple:
→ All encryption happens locally.
→ Secrets are stored as encrypted blobs in your private repo.
→ GitHub is treated as untrusted storage.
→ No plaintext secrets ever leave your machine.
→ No plaintext secrets are stored on disk.
Most secret managers either require a hosted backend, a self-hosted server, or trusting a SaaS provider. I wanted something that:
→ Requires zero infrastructure
→ Uses tooling developers already have
→ Keeps the threat model simple
AxKeyStore uses a layered approach to security:
→ Secrets are encrypted with a Remote Master Key (RMK).
→ The RMK is encrypted with your master password and stored in the repo.
→ A Local Master Key (LMK) encrypts your local GitHub token and repo config.
→ The LMK itself is encrypted using Argon2id-derived keys from your master password.
→ Encryption uses XChaCha20-Poly1305 (AEAD).
GitHub only sees encrypted binary blobs. Even if someone compromises your repository, they still need your master password to decrypt anything.
Why GitHub? Because it gives:
→ Private repositories
→ Version history (commit log as audit trail)
→ Access control
→ Free storage
→ Global availability
Instead of building a backend, I’m leveraging an existing, reliable system - but cryptographically isolating it.
Features
→ Simple CLI workflow
→ Hierarchical categories (e.g., cloud/aws/prod)
→ Version history per secret (via commits)
→ Retrieve specific versions by SHA
→ Multi-profile support (separate vaults)
→ Transactional master password reset
→ Secure random secret generation
Tech
→ Written in Rust. Uses tokio, clap, argon2, and chacha20poly1305.
→ There are unit and integration tests (including mocked GitHub API interactions).
→ Open source - MIT licensed.
I’d appreciate feedback on:
→ The threat model - what am I missing?
→ Whether GitHub as encrypted blob storage is a bad assumption
→ UX improvements for CLI-based secret workflows
→ Any crypto or key-handling concerns
I’m especially interested in critique from people who’ve built or audited secret management systems.
Thanks.
I built AxKeyStore, an open-source CLI tool for managing secrets that uses your own private GitHub repository as encrypted storage.
The idea is simple: → All encryption happens locally. → Secrets are stored as encrypted blobs in your private repo. → GitHub is treated as untrusted storage. → No plaintext secrets ever leave your machine. → No plaintext secrets are stored on disk.
Most secret managers either require a hosted backend, a self-hosted server, or trusting a SaaS provider. I wanted something that: → Requires zero infrastructure → Uses tooling developers already have → Keeps the threat model simple
AxKeyStore uses a layered approach to security: → Secrets are encrypted with a Remote Master Key (RMK). → The RMK is encrypted with your master password and stored in the repo. → A Local Master Key (LMK) encrypts your local GitHub token and repo config. → The LMK itself is encrypted using Argon2id-derived keys from your master password. → Encryption uses XChaCha20-Poly1305 (AEAD).
GitHub only sees encrypted binary blobs. Even if someone compromises your repository, they still need your master password to decrypt anything.
Why GitHub? Because it gives: → Private repositories → Version history (commit log as audit trail) → Access control → Free storage → Global availability
Instead of building a backend, I’m leveraging an existing, reliable system - but cryptographically isolating it.
Features → Simple CLI workflow → Hierarchical categories (e.g., cloud/aws/prod) → Version history per secret (via commits) → Retrieve specific versions by SHA → Multi-profile support (separate vaults) → Transactional master password reset → Secure random secret generation
Tech → Written in Rust. Uses tokio, clap, argon2, and chacha20poly1305. → There are unit and integration tests (including mocked GitHub API interactions). → Open source - MIT licensed.
I’d appreciate feedback on: → The threat model - what am I missing? → Whether GitHub as encrypted blob storage is a bad assumption → UX improvements for CLI-based secret workflows → Any crypto or key-handling concerns
I’m especially interested in critique from people who’ve built or audited secret management systems.
Thanks.