It has been a few years since I looked at my GPG keys, and the security defaults have since shifted greatly!
So, I decided it was time to update my password-store database with a new key that was more secure, while also affording me the opportunity to clean up a mess of 14 keys that I never use (most of which were expired.)
This will be a quick guide on how to setup new keys, migrate a password-store database to the new key, and then back up these keys for the future.
Please note that while your public key can be (and should be!) shared around, your private key should always remain under lock and key, offline, and kept safe.
Why you should use a password database #
You should have no idea what your passwords are.
Too many people use the same password everywhere (or at best, a variation of that password they use everywhere) and when data breaches inevitably happen, they are easy targets for a hacker to get into any and all of their services.
I know only one password that unlocks a database, but I have no idea what my passwords are across the hundreds of logins I have.
This is good practice, and it doesn’t have to be difficult; Bitwarden and Keepass make this fairly painless for the average person. Simply initiate a new database, keep that file safe, and use it on your phone and machines painlessly. Use one, set it up today, and start NOT knowing your passwords.
Password-store is the pinnacle of password managers #
I use the Standard Unix Password Manager as my password solution for the simple reason that it is scriptable, portable, and secure. Using GPG keys, pass is a script that encrypts all passwords as you create them. These are simple text files that are then portable to backup in a git repo.
We like text files here, and encrypted text files are all the better.
Here is how to manage GPG keys, create new ones, and then migrate a Pass database to new keys.
See the current keys you have in your keychain #
gpg --list-keys
This will show you any and all keys you have in your system and allow you to see their IDs for management.
Delete unused keys #
gpg --delete-secret-keys ID-OF-KEY
gpg --delete-keys ID-OF-KEY
You will have to delete the secret key before the public key. I had 14 keys, of which I have no idea when I created 12 of them…
Create new gpg key #
gpg --full-generate-key
I noticed the defaults have changed away from RSA (I set my old key to RSA 4096 in 2021).
Reinitialize the password-store database with the new key ID #
echo "new-key-id" > ~/.password-store/.gpg-id
pass init <new-key-id>
This will change the key in your .gpg-id file inside your password-store directory, and then re-initialize the database with the new key.
Export Keys for Backup #
gpg --export --armor new-key-id > public-key.asc
gpg --export-secret-keys --armor new-key-id > private-key.asc
Keep both files safe from the export for future use. You can share your public key for gpg encrypted email and file sharing, but keep the private key, well, private.
Import Keys to new Machine #
gpg --import public-key.asc
gpg --import private-key.asc
and then trust the new key:
gpg --edit-key new-key-id
gpg> trust
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
Your decision? 5
You are now set to use this new key and encrypt your passwords for future use!