Navigate to… Terms and acronyms What this is, and how to read it Passwords for programs, and why we refuse them Envelope encryption: the key idea The mailbox trick: public-key encryption Signing is not encrypting Locks and keys: symmetric encryption Who are you defending against? The two questions every secrets system must answer What a secret is Why secrets leak The cast of characters Where your private key actually lives What we deliberately do not have The bet: the server should be powerless How the layers stack Asserted vs attested: two very different promises Two modes, one format The uncomfortable truth we start from What the audit log can tell you phase 3 Bus factor When two people write at the same time The weekly checkup Fingerprints, and how trust is kept over time Giving someone access You lost your key. Now what? Reading a secret Taking access away The three rotations Versions, and how a secret changes without breaking anything Writing a secret Backups and drills Create an organization (serverless) Config reference Install Onboard a machine (CI, a service) Turn on the server (optional) phase 3 Onboard a teammate Asserted custody cannot be enforced We cannot protect you from your own machine Metadata leaks even though contents do not Stolen ciphertext can be attacked forever Cloud misconfiguration is outside our reach Revocation is not retroactive, and serverless mode has no read log You have to trust the client itself Command cheat sheet Glossary What a secret is¶
A secret is a piece of information whose only protection is that few people know it . A database password protects your database because the string is not widely known. The moment it is widely known, it protects nothing, and there is no way to un-know it.
That last part is the whole problem. A stolen laptop can be wiped. A stolen password cannot be un-read. This is why everything below eventually comes back to changing secrets rather than hiding them better.