PGP
Full Title or Meme
PGP or pretty good privacy, as an early attempt to create secure email with no central control.
ViaCrypt
Created the first commercial version of PGP with a full RSA license and hardware encryption token from National Semi created by Tom Jones.
Chris Allen
2024-12-15 Having been involved with PGP since the early 90s (I licensed them RSAREF, the only patent license available to free software developers), I have moved almost away from PGP Keys to SSH for everything. In fact, the origin of the Rebooting Web of Trust was meeting with the former CTO of PGP and we both agreed it was time to retire it and start over.
I have two DID napkin sketches related to SSH that I'm playing around during some free time I'm hoping to get during the holiday break.
The first is a did:key style method that uses SSH keys which can be bootstrapped from GitHub/GitLab, etc.
For instance, you can get my SSH Auth Keys from GitHub:
``` % % curl https://github.com/ChristopherA.keys ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMNOXm9gTvmGKttlmTchKqiQcqLObHgfABjSmGzZk4DY
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICs/ct9OdmHmfXNNdDpHnTY0O5Ru5EFaa0LNMBvF5p9U
```
More importantly, since I practice key separation, you can also get my signing keys GitHub:
``` % curl https://api.github.com/users/ChristopherA/ssh_signing_keys [
{
"id": 184891,
"key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINTazxjqxsdh3Sv/7fxSTgr3qlCVByYoGDHHe428Fubp",
"title": "eurynome.local/sign_id_25519_christophera@github.com",
"created_at": "2023-10-26T06:28:34.882Z"
},
{
"id": 219925,
"key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMU0/lvWurXvUcrvYNgfb02Ska0qpwC/yv22dvDIxxzh",
"title": "kymindis.local/sign_id_ed25519_christophera@github 2024-01-04",
"created_at": "2024-01-04T20:13:55.503Z"
},
{
"id": 233116,
"key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIC2O9n9I7RK1DXvnd7+eKYT+0Cr1bCJvdN/pdkb7625S",
"title": "sign_id_ed25519-mnemosyne.local-christophera@github_2024_02_26",
"created_at": "2024-01-26T21:35:28.362Z"
}
] ```
There are equivalent web APIs for GitLab and most other git services.
The second area is leveraging git inception hashes (a specially formatted and SSH signed first "0" commit to establish a root of trust for the repo, since the SHA1 hash is weak).
You can see an example the one I'm playing around with in the commit message for this inception commit: https://github.com/ChristopherA/Open-Integrity-Inception-Test/commit/c22a885cc662aa0843c6f8523ddde6cbd9bafe69
``` Initialize repository and establish a SHA-256 root of trust Signed-off-by: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIC2O9n9I7RK1DXvnd7+eKYT+0Cr1bCJvdN/pdkb7625S;2C <U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgLY72f0jtErUNe+d3v54phP7QKvVsIm903+l2RvvrblIAAAAEZmlsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQyNTUxOQAAAEB8USEis6d49g/F6SRPlyLz6q5nmsbDDg+OncxMGH2zLHmGbPDaVF6SGdMYR5M9Gr+SyHn4sP1trq/ohFENnckD>
This key also certifies future commits' integrity and origin. Other keys can be authorized to certify additional commits via the creation of an ./_repo:allowed_commit_signers file. This file must initially be signed by the repo's inception key, granting these keys the authority to certify future commits to this repo, including the potential to remove the authority of this inception key for commits. Once established, any changes to ./_repo:allowed_commit_signers must be certified by one of the previously approved signers. ```
This might resolve to a DID document something like:
```
{
"@context": "https://www.w3.org/ns/did/v1",
"id": "did:repo:deedb3380e3e75266a009ee43b1dec54619f1b0f",
"verificationMethod": [
{
"id": "did:repo:deedb3380e3e75266a009ee43b1dec54619f1b0f#ssh-key-1",
"type": "SshPublicKey",
"controller": "did:repo:dbe44e2f99347b403b8b649605dd718bf5a69614?serviceEndpoint=https%3A%2F%2Fgithub.com%2FChristopherA%2FChristopherA"
"publicKeySsh": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIC2O9n9I7RK1DXvnd7+eKYT+0Cr1bCJvdN/pdkb7625S"
}
],
"authentication": [
{
"id": "did:repo:deedb3380e3e75266a009ee43b1dec54619f1b0f#ssh-key-1",
"type": "SshPublicKey",
"controller": "did:repo:dbe44e2f99347b403b8b649605dd718bf5a69614?serviceEndpoint=https%3A%2F%2Fgithub.com%2FChristopherA%2FChristopherA"
"publicKeySsh": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIC2O9n9I7RK1DXvnd7+eKYT+0Cr1bCJvdN/pdkb7625S",
"proofPurpose": "authenticationCommitOnly" // Indicating restricted use specifically for commit authentication
}
]
}
``` You can see some of my raw notes about this at https://gist.github.com/ChristopherA/dcf963c3849bc0d67b35c215efd15f86. They can be used to bootstrap an "Open Integrity" system using DID that point to distributed git repos (not github or gitlab, but the repo hash), that can serve as DID documents, as self-signed verifiable credential data stores, or serve to carefully protect the provenance of the entire contents of a git repo.
All of this can be accomplished completely through git, ssh-keygen, and a shell scripting language (I currently use zsh.). No blockchain or custom cryptographic code required. Longer term, I'm hoping to add transition to using Gordian Envelope to leverage the ability to elide keys — we added SSH capability to our envelope cli too earlier in the year: https://github.com/BlockchainCommons/bc-envelope-cli-rust
My raw notes are getting somewhat dated, as I had to set this project aside for paid opportunities, but as I said, my goal is to get some kind of working proposal over the holidays (unless you want to sponsor my work, or join in contributing code to the project, and I'll accelerate it!)
The key thing you need to know is that most security people now say that PGP/GPG should not be used for email. See:
https://www.wired.com/story/efail-pgp-vulnerability-outlook-thunderbird-smime/ which highlights inherent issues with PGP, such as its age, complexity, and lack of forward secrecy, making it less suitable for modern secure communications.
The main value of GPG in the last decade has been for file signing, as git has supported it for some time. For instance, Bitcoin has an elaborate GPG multiparty signing process of tagged releases. See the most SHA256SUMS files in the most recent tagged release at https://bitcoincore.org/bin/bitcoin-core-28.0/, and the process has become fairly arcane, see: https://coinguides.org/verify-bitcoin-core-signatures/
However, git introduced support for signing commits and tags with SSH keys in version 2.34.0 (November 15, 2021), leveraging OpenSSH's data-signing capabilities introduced in OpenSSH 8.0. GitHub began supporting SSH commit verification on August 23, 2022, followed by GitLab in version 15.7, released on December 22, 2022. These developments allow developers to use SSH keys for both authentication and commit signing, simplifying code authenticity verification. SSH also now offers support for many cryptosystems, including some that are quantum resistant.
At Blockchain Commons, we currently use both SSH detached signatures for signing tagged releases of more security sensitive applications. For instance, see all the attached files in https://github.com/BlockchainCommons/GordianServer-macOS/releases/tag/v1.1.0. Our goal is to eventually have all of our tagged releases use a verifiable approach including not just apps but also all our libraries. On our roadmap in 2025 are better build tools to make this easier.
I have two gists about Git and SSH signing. Note that I use gists for rough drafts, notes and lists, and they have not been reviewed.
- SSH Keys Best Practices https://gist.github.com/ChristopherA/3d6a2f39c4b623a1a287b3fb7e0aa05b - Links regarding SSH Signing Best Practices: https://gist.github.com/ChristopherA/3d6a2f39c4b623a1a287b3fb7e0aa05b
I have a bunch of other SSH related gists available at https://gist.github.com/search?q=user%3Achristophera+ssh
