starekrow

When I did the first pass at this architecture about 6 years ago, we had a few servers in a rack at a local datacenter as well as virtual servers at Rackspace and AWS.

Since then, I haven't shed the habit of designing for the general case (this is also known as avoiding vendor lock-in :)

Why not? :D

More seriously, because LAMP stacks are ubiquitous, well understood and well supported by vendors. Also, the output of this code is trivial to use or replicate in most other languages - in fact, I've got some fragments of C source lying around for a similar system, that was intended for a command-line tool that would interoperate with a distant ancestor of Lockbox.

That concern for future interop possibilities is the main reason it stores secrets in JSON - which is one reason, along with abysmal character encoding practices by many developers, that the key and ciphertext is all ASCII-safe. A 30% bump in output size is more than offset by never having to care what transport those strings are moving through.

I hadn't actually considered adoption at any scale - I just thought the overall approach was cool, and the code might be useful to folks looking for this exact thing. The PSRs were lurking in the back of my thoughts during the cleanup for publication, though. Argh. They're a bit outside my normal coding style.

Re: libsodium, there will be optional support for it at some point precisely because it's going into the core, but I try to do all my components like this with no required dependencies. I'm not even entirely satisfied with Lockbox requiring the openssl extension, but that's far preferable to yet another homespun AES implementation.

I use it to store database passwords and AWS API keys on EC2 instances that are running web servers. When combined with a dead simple key distribution client/server setup, you can sleep a bit better knowing that even if someone managed to copy the entire hard drive, they wouldn't get your keys. Of course, if they get root on the box in operation it's all over, but anything short of that should be survivable. It beats the hell out of writing them all in the clear to "config.php" and checking that in with the rest of your site source.

I've also used similar code to manage an encrypted file store for a small business - since each file gets its own locks (essentially a cryptographic ACL) and each attached key is publicly identified, it's easy to see who can read (or change) any given file. Being able to remove lockboxes without decrypting the data means that a sysadmin can strip access from someone who leaves the company without needing an all-powerful "root" key.

Ack. You are absolutely right, that was my own copy/paste issue. Fixed now, thanks!