This is the process I use for password management. Thought it might be valuable to get the details written down in case that bus that's going around cleaning up sys-admins has another stop.

So, you know how GPG is a smidge controversial? What with the suboptimal defaults and occasional vulnerabilities...

Well, what if we just ignored all of that because our priority was longevity.

GPG isn't going anywhere. I suspect that we will still be able to run it in one way or another for the next 20 years (assuming there are still people by then). So if your concern is state of the art post-quantum encryption then great, there are other options, but if you're looking for boring, stable and sedentary, then maybe GPG is the three-legged horse for you!

So I wrote Paw. It is yet another password manager. This article isn't an ad, you probably shouldn't actually use Paw. But it pokes tiny little needles into my particular itches:

• It stores GPG encrypted password files on your private server
• Transfers your secrets (without actually copying files) via ssh and pipes
• Decrypts the remote secrets and loads them into the local copy-paste buffer
• Allows you to keyword search the password store without needing to decrypt anything first
• Caches the decryption password for a specified duration

Paw sends shell commands over ssh to search for the password you need. Let's make ssh stop prompting for passphrases (for a short while).

Reduce ssh friction

# start ssh-agent with an authentication timeout of (eg) 12 hours

$ ssh-agent -t 12h bash -l

# add your ssh key into the agent

$ ssh-add Start Paw by pointing it at a remote host and remote path where the passwords will live.

paw

$ paw my-secret-host:/path/to/passwords

# You'll get prompted with the instruction to create or search credentials

# Let's create a new credential, by entering the text "new"

my-secret-host: gpg (GnuPG) 2.2.40 Enter "new" or search for: new

# It tells you what file it's going to create

Intending to create: my-secret-host:/path/to/passwords/23.asc

# Enter the username for the credential

username: test@gmail.com

# Enter the password (it'll use apg to display an example)

password (e.g. Whoop*ewo2ichIfN3ijci@@t4egtEm): Whoop

# There's an extra field for a secondary secret

additional secret: the security question, mother's maiden name was lemonade

# Give it some keywords, so you can search for it in future

searchable keywords: gmail login

# And then enter a GPG encryption password

Enter passphrase Passphrase: (hidden) Repeat: (hidden)

# And paw will write it in ascii armoured encrypted text on the remote host

Wrote: my-secret-host:/path/to/passwords/23.asc Let's take a look at what was actually created:

my-secret-host:/path/to/passwords/23.asc

# Note the searchable keywords are not stored encrypted

# this makes searching fast since we only decrypt what we need

-----BEGIN PGP MESSAGE----- Comment: gmail login jA0ECQMIkgUz7Hw/IJD/0loBOEeCTW/wmTFlxMDC7IPYhTDN2gVFURLshwMcidBF iDaP9JIcJDoBfIr23FgzA6127chDShnZih0wEWDw8ume/mJZTUUBTqO1vWFF1bwO Mf2iyRKkxhY+fbE= =IvEF -----END PGP MESSAGE----- Now let's search for the credential. The search makes use of the keywords we entered that are stored in GPG's plaintext "comment" field.

If it finds any matches, then the final match is decrypted and the contents pushed into your local copy-paste buffers. It does this:

1. Without copying the files between your local server and the remote server
2. Without modifying the files on the remote server
3. Without leaving behind decrypted copies of the data anywhere

The copy-paste commands support xclip (Linux default), wl-copy (Wayland), and pbcopy (MacOS). The xclip default allows only three pastes before the contents are wiped.

Search for a credential

# Let's search for the keyword "login"

my-secret-host: gpg (GnuPG) 2.2.40 Enter "new" or search for: login /tmp/ppp/23.asc:Comment: gmail login /tmp/ppp/27.asc:Comment: hotmail login gpg passphrase: (hidden) wrong-one@hotmail.com

# Oops not specific enough, it loaded up the hotmail login by accident

# Let's search on "gmail" instead

Enter "new" or search for: gmail /tmp/ppp/23.asc:Comment: gmail login gpg passphrase: (hidden) test@gmail.com the security question, mother's maiden name was lemonade Now the username (printed above) just got automatically loaded into the "primary" buffer and the password (not printed above) got loaded into the "clipboard" buffer.

The primary (username) buffer can be pasted on linux using middle-click. The clipboard (password) buffer can be pasted using ctrl-v.

No web interface or mischievous GUI. No opaque storage locations or file formats. Just one centralized store of GPG encrypted files, wherever you want them to be, that can only be accessed via ssh and decrypted with a password...

Er yes, password. The files are encrypted using symmetric encryption instead of GPG keys. I've outlined the reasons over on the github page, but essentially it boils down to accessibility.

I understand the value of public/private asymmetric encryption, but here are my thoughts for just this specific context:

• Over the years it seems likely that one will misplace, or inadvertently leak their private key file. Depending on your level of preparedness, it might be an unrecoverable situation
• Sadly, through convenience, my private GPG keys will almost certainly end up existing on multiple laptops and servers. I'll lose track of them. (It's very conceivable that any new devices will need access to a password!)
• A passphrase for a GPG key will still need to be stored by some mechanism (and don't say: "the password manager")
• GPG keyrings and the importing and exporting of keys, and specifying recipients is juuust difficult enough...
• And most importantly to me: the use of GPG keys will make it harder to transfer the ability to decrypt, to my family members

Passwords also have their obvious weaknesses, but "losing them" isn't something that's in my DNA. I like that they can be written down. Put in a will. Or intentionally shared with ease.

My concerns are not ones of national security. I am prioritizing long-term access over long-term safety insofar as the encryption goes.

As far as ssh access goes: it's intended to be a rock solid network barrier, that is intentionally circumventable given physical access to the hardware.

My hope is that this will provide my family with a skerrick of a chance to access my accounts (if need be) in the unforseeable future. And in the meantime, I quite like having private centralized access to my passwords, without depending on another fucking company.