3 ms·

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. E

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 12y ago
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.