Repository navigation
Upload PGP key (fingerprint) to distinct domains (out-of-band TOFU cross-reference) #353
Description
Activity
Part Two: Documenting it
After uploading your public key and/or full fingerprint to as many distinct domains as possible, please update the project's documentation to enumerate all of the domains where a user can find the PGP Key (or key fingerprint)...
For an example of how another security-focused open-source project has documented how users can obtain their release-signing PGP key from multiple domains out-of-band, see:
Upload the KickSecure Release-Signing PGP key onto multiple domains, and
Kicksecure signing-key-mirrors
https://keyserver.ubuntu.com/pks/lookup?search=KickSecre&fingerprint=on&op=index
Typo
KickSecre(wrong) vsKicksecurecorrect. There is indeed no match even without the typo. There is a match when looking foradrelanos.And there are "false results" when searching for
Whonix.
https://keyserver.ubuntu.com/pks/lookup?search=whonix&fingerprint=on&op=indexExpecting users to find out which key is real versus fake is quite a steep learning curve.
Please add your public keys as a files somewhere in this GitHub repo
https://infra.apache.org/release-signing#keys-policyI am not sure that is great idea. There's ~ 80 or so repositories. Adding the key to every repository would add quote some extra noise on top of other repetitive files such as license files.
If someone knows how to use git and OpenPGP
git verify-commit HEAD git log --show-signatureAnd find out key fingerprints that way.
sequoia-git (Git commit signing policy verifier) might be useful.
https://sequoia-pgp.gitlab.io/sequoia-git/user-manual/
https://sequoia-pgp.gitlab.io/sequoia-git/man/sq-git-log.1.html
https://fosdem.org/2026/schedule/event/KFSUCW-sequoia-git/Running blindly
gpg --import KEYSwithout prior checking which keys with what fingerprints would be imported would be insecure except in a trust on first use threat (TOFU) model.derivative-maker actually has
keys/derivative.ascandderivative-updatealso supports TOFU. However, best if the user follows the build documentation which leads to manual key fingerprint verification.Debian policy 4.11. Upstream source location: debian/watch suggests file:
debian/upstream/signing-key.ascRelated,
uscan:
https://manpages.debian.org/uscanMore discussion here:
https://forums.whonix.org/t/genmkfile-lintian-debian-watch-may-check-gpg-signature-build-issue/19124It's possible for a very powerful adversary to compromise your release infrastructure (or the infrastructure between the server and the client) and get a new KickSecre user to download a malicious version of the release, signature, and the release signing key -- but it's exponentially more difficult for them to compromise multiple distinct domains.
Remember: monero's release infrastructure has already been comprimised once. And here's a great list of historically relevant cases where this happened:
Would your suggested solution have prevented this? I don't think so. Because once an adversary can upload malicious binaries to
web.getmonero.orgthey adversary could also replace the signing key instructions onweb.getmonero.org.https://www.kicksecure.com/wiki/Verifying_Software_Signatures
That page is more of a general computer security education wiki page. Mostly general and unspecific to Kicksecure.
The Kicksecure specific digital signature verification instructions are here:
https://www.kicksecure.com/wiki/Verify_the_imagesThat page leads to:
https://www.kicksecure.com/wiki/Main/Project_Signing_KeyWhich also leads to:
https://www.kicksecure.com/wiki/OpenPGP#Bootstrapping_OpenPGP_Keys_from_the_InternetCareful readers / advanced users have a chance to learn about all of this.
How about less careful readers? They don't have a chance:
https://www.kicksecure.com/wiki/Verifying_Software_Signatures#Unfixable_Documentation_Usability_IssueWould your suggested solution have prevented this? I don't think so. Because once an adversary can upload malicious binaries to web.getmonero.org they adversary could also replace the signing key instructions on web.getmonero.org.
I would say yes, because educated users will try to check multiple, distinct domains (eg your mastodon account, your twitter account, your subreddit, your GitHub org profile, your website documentation, and popular keyservers) for your key. They would notice the discrepancy and then open a bug report about it (I recently did this with SimpleX, for example, because their release signing key changed and they didn't publish a key transition notice -- which raised a red flag).
If your key is only available on one domain, then your users can only TOFU and wait, which is far more risky than checking multiple distinct domains
I am not sure that is great idea. There's ~ 80 or so repositories. Adding the key to every repository would add quote some extra noise on top of other repetitive files such as license files.
I would definitely not upload it to >1 repository. Pick one and document it. I opened this ticket in
security-miscbecause it seemed to me that it would be the appropriate repo for this to live, based on its name.
This ticket is a request to:
Why?
It's possible for a very powerful adversary to compromise your release infrastructure (or the infrastructure between the server and the client) and get a new KickSecre user to download a malicious version of the release, signature, and the release signing key -- but it's exponentially more difficult for them to compromise multiple distinct domains.
Remember: monero's release infrastructure has already been comprimised once. And here's a great list of historically relevant cases where this happened:
Part One: Making key available out-of-band
openpgp.org
keys.openpgp.org is a newer keyserver that doesn't sync with the others, and it strips UIDs and signatures by default for privacy and to resist certificate spamming attacks
Unfortunately, I could not search for your key on this server.
Please upload the official KickSecure Release Signing PGP Key to OpenPGP.org
SKS Keyservers
Unfortunately, I could not find the KickSecre key on the traditional SKS keyservers.
There's many SKS Keyservers, and KickSecre can minimize the risk that a user downloads a malicious key by uploading their key to at least one of the SKS keyservers, such as keyserver.ubuntu.com.
Please upload your release-signing key(s) to an SKS keyserver.
GitHub
Please add your public keys as a files somewhere in this GitHub repo
I recommend creating a new
KEYSfile, following the best-practice standard from Apache:Reddit
Please add your public keys' full fingerprint (
916B 8D99 C38E AF5E 8ADC 7A2A 8D66 066A 2EEA CCDA) to the sidebar of your subreddit:Mastodon
Please add your public keys' full fingerprint (
916B 8D99 C38E AF5E 8ADC 7A2A 8D66 066A 2EEA CCDA) as a new Profile Field in your official mastodon account.Twitter
Please add your public keys' full fingerprint (
916B 8D99 C38E AF5E 8ADC 7A2A 8D66 066A 2EEA CCDA) to your account description of your official twitter account.Other domains
I do recommend adding your key to as many other domains as possible, including:
The more domains you upload it to, the better.
Part Two: Documenting it
After uploading your public key and/or full fingerprint to as many distinct domains as possible, please update the project's documentation to enumerate all of the domains where a user can find the PGP Key (or key fingerprint) and write a paragraph to describe how the user can mitigate the risk of compromised infrastructure by cross-checking the integrity of the key across multiple domains.