github.com/StackExchange/blackbox/v2@v2.0.1-0.20220331193400-d84e904973ab/docs/encryption.md (about)

     1  How is the encryption done?
     2  ===========================
     3  
     4  GPG has many different ways to encrypt a file. BlackBox uses the mode
     5  that lets you specify a list of keys that can decrypt the message.
     6  
     7  If you have 5 people ("admins") that should be able to access the
     8  secrets, each creates a GPG key and adds their public key to the
     9  keychain. The GPG command used to encrypt the file lists all 5 key
    10  names, and therefore any 1 key can decrypt the file.
    11  
    12  Blackbox stores a copy of the public keys of all admins. It never
    13  stores the private keys.
    14  
    15  To remove someone's access, remove that admin's key name (i.e. email
    16  address) from the list of admins and re-encrypt all the files. They
    17  can still read the .gpg file (assuming they have access to the
    18  repository) but they can't decrypt it any more.
    19  
    20  *What if they kept a copy of the old repo before you removed access?*
    21  Yes, they can decrypt old versions of the file. This is why when an
    22  admin leaves the team, you should change all your passwords, SSL
    23  certs, and so on. You should have been doing that before BlackBox,
    24  right?
    25  
    26  *Why don't you use symmetric keys?* In other words, why mess with all
    27  this GPG key stuff and instead why don't we just encrypt all the files
    28  with a single passphrase. Yes, GPG supports that, but then we are
    29  managing a shared password, which is fraught with problems. If someone
    30  "leaves the team" we would have to communicate to everyone a new
    31  password. Now we just have to remove their key. This scales better.
    32  
    33  *How do automated processes decrypt without asking for a password?*
    34  GPG requires a passphrase on a private key. However, it permits the
    35  creation of subkeys that have no passphrase. For automated processes,
    36  create a subkey that is only stored on the machine that needs to
    37  decrypt the files. For example, at Stack Exchange, when our Continuous
    38  Integration (CI) system pushes a code change to our Puppet masters,
    39  they run `blackbox decrypt --all --overwrite` to decrypt all the files.
    40  The user that
    41  runs this code has a subkey that doesn't require a passphrase. Since
    42  we have many masters, each has its own key. And, yes, this means our
    43  Puppet Masters have to be very secure. However, they were already
    44  secure because, like, dude... if you can break into someone's puppet
    45  master you own their network.
    46  
    47  *If you use Puppet, why didn't you just use hiera-eyaml?* There are 4
    48  reasons:
    49  
    50  1. This works with any Git or Mercurial repo, even if you aren't using Puppet.
    51  2. hiera-eyaml decrypts "on demand" which means your Puppet Master now uses a lot of CPU to decrypt keys every time it is contacted. It slows down your master, which, in my case, is already slow enough.
    52  3. This works with binary files, without having to ASCIIify them and paste them into a YAML file. Have you tried to do this with a cert that is 10K long and changes every few weeks? Ick.
    53  4. hiera-eyaml didn't exist when I wrote this. (That's the real reason.)
    54