

Show HN: Secure key distribution (in Go) - jfindley
http://getskds.io/

======
e12e
I'm a little confused about what problem this solves. According to the
documentation, secrets are encrypted by each clients unique key, and the
server only has a copy of the encrypted secret? So the sensitive data is
essentially still on a single client: lose the keys and none of the secrets
can be recovered?

~~~
jfindley
I'll see if I can re-work the documentation a bit to make this clearer - I
think in the hope of making it easy to understand I oversimplified a bit too
much.

Each secret has a unique key generated for it on the machine uploading the
secret. The unique key is also uploaded to the server, but encrypted
(initially for super users and the owner only), and it's this unique key for
the secret that's shared. This means that the server cannot read the secret
(it never gets the decrypted key), but the secret can be shared with clients
without having to maintain lots of copies of the secret itself (which could
potentially be large). The sharing mechanism is a bit involved, as it has to
happen without any decryption on the server, but I'll try document this
properly.

To get into a situation where secrets were unrecoverable, you'd have to lose
all your super-user keys and all the admin/client keys with access.

Does that clear things up at all?

~~~
e12e
Yeah, that makes a lot more sense ;-) (I actually even glanced at the source,
but with the wrong idea from the docs, it wasn't immediately obvious that the
server/users were able to access the plain-text keys -- which of course made
the whole thing seem a little absurd).

Does sound like you've kind-a-sort-a reimplemented half of kerberos... I've
been mulling the idea of doing that myself, leveraging NaCl, and maybe
something simpler than DNS/ldap -- but I'm not convinced it makes sense. I
suppose kerberos doesn't really offer any arbitrary access to key-values
(that'd be eg ldap, and those aren't encrypted with only user-keys) -- so the
ideas just overlap a bit, without one making the other redundant.

------
earless1
I've been looking to build something like this, but backed by ETCD. I've had
the hardest time finding other implementations or even figuring out what to
call such a system. Credential storage and management is hard, especially in a
large environment.

~~~
jfindley
You could easily store the client configs in etcd then just deploy the client
with whatever bootstrapping you use if you wanted to go down that route.

As long as the client knows what it's called and where the server is, it
doesn't need anything else - designed to be as simple and lightweight to
deploy as possible.

