I'm aware of the context parameter passed to KMS, and it is indeed something I plan on adding - one step at a time!
This was largely a side project that's gone quite well so far(!) - it's something I'll continue to add to. Any other suggestions are more than welcome.
Like it says in the readme, I just wanted a simple (single binary) deployment - it's in no way a dig at credstash.
A secure storage system shouldn't allow passwords as keys. If passwords are a thing that is going to happen, the API should be structured so that those passwords get run through a KDF. That's what he's getting at.
You can do that, but a better API design is one that simply ensures keys are always random. KDF'd passwords are still weaker than real cryptographic keys.
A common design pattern is to use KDF keys as key-encrypting keys wrapping fully random keys. The system in steady-state relies only on the fully random key; the KDF key, depending on the design, can sometimes be kept offline. This is how SSH and GPG handle keys: note how the actual keys the system uses are fully random and totally out of the user's hands.
But you might not need any of this mechanism at all; it might be totally possible to design this system such that keys are simply blobs, generated via urandom by reading crypt.Rand.
The binaries don't support Postgres (though it's a 2 minute job to add) because the drivers aren't included in the build, though the library can support it.
The underlying SQL uses "?" as a parameter binding placeholder, Postgres uses $1, $2 right?
Seems like an obvious oversight, I can put up a build if you're willing to test it?
This was largely a side project that's gone quite well so far(!) - it's something I'll continue to add to. Any other suggestions are more than welcome.
Like it says in the readme, I just wanted a simple (single binary) deployment - it's in no way a dig at credstash.