That’s the problem. Getting into “why key length changed” gets into more and more complicated details.
Reason for changing: Because the key expired. The key has been extended. It depends on the definition of “the same key”. It’s the same key fingerprint, key owner, algorithm, but a different expiration date. So it would also be correct to say it’s not “the very same key”. In GnuPG terminology, it seems this is considered “the same key but extended”.
If you need to ask over https/onion, then you cannot benefit from copying/pasting these commands because it is a complicated answer. Documented here: Verifying Software Signatures
Specifically in the chapter Conceptual Challenges in Digital Signatures Verification.
(The same challenges exist when initially installing Debian (non-Qubes), Fedora, Ubuntu, Qubes etc.)
In other words, to gain the security benefits of key verification, you need to know how to perform key verification without relying on TLS/onion such as by asking forums, AI, etc.
I could write commands that someone could copy/paste without their own technical understanding, or even provide a script. But using these commands is no more secure than copying the signing key without verification, and the script would actually be even less secure.
In other words, if you must ask how to do it, you likely cannot do it securely.
The Tails project reached a similar conclusion. Quote Tails - Download verification (bold added):
OpenPGP signatures
Unless the user knows how to verify the signing key through the OpenPGP Web of Trust, this technique ultimately relies on a correct download of the signing key and signature, and thus on HTTPS.
OpenPGP verification instructions
We removed the instructions to verify downloads with OpenPGP because:
- Without advanced knowledge of OpenPGP, verifying with OpenPGP provides the same level of security as the JavaScript verification on the download page, while being much more complicated and error-prone.
- None of our personas would have enough knowledge of OpenPGP to use the OpenPGP Web of Trust with confidence.
- Providing basic (and never exhaustive) instructions has proven to be very time consuming to our help desk and technical writers. See #17900.
We still explain how to verify our signing key using the OpenPGP Web of Trust in the installation instructions from Debian, Ubuntu, or Mint using the command line and GnuPG because Debian derivatives come with trusted OpenPGP keys that can be used to create a path to our signing key.
Right, and given said above, and given…
This is complicated stuff, and as early as 1999 the Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0 paper has been published.
[1]
There seems to be literally no way to make the documentation on that topic uncomplicated.
There are some things which are so complicated they cannot be learned through documentation alone. Read a book and become a heart surgeon? No way. Become “at least” a general practitioner? Also no way. Learning by doing, sitting together in the office of a general practitioner for years: can doctor skills be learned through on the job training, listen, observe and imitate? Also no way. In many countries it requires about 12 years of study. Now maybe that could be compressed or some bright minds could learn it faster but it still cannot be compressed to 1 year. In any case, there is no way to “write simple documentation”.
Now that’s a bit far fetched. Learning the OpenPGP Web of Trust probably won’t take years of study. I would guesstimate it would take several hours or days and may require a teacher. There may be OpenPGP courses and cryptoparties (at least used to exist). I mention this to illustrate there is no way to have simple documentation for this complex topic.
I didn’t accuse you. Therefore, I worded it as:
I don’t know if you would have posted the expected reply, and that doesn’t matter. In my experience, this reply is highly likely something that would come up in the mind of a reader or might even be posted as a comment.
And often I reply not only to what a specific user asked but with a general audience in mind.
While I was holding that thought, I decided it would be good to complete the post right now with highly-likely follow-up comments, to avoid having to rehash and address this later.
No.
No.
Unsure.
No.
No.
Indeed.
There have been issues with gpg keyservers.
(SKS Keyserver Network Under Attack · GitHub)
In response, upstream gpg made many changes and introduced new bugs.
Changes such as:
Bugs such as:
And the bug apparently most relevant on the topic of including third-party signatures when exporting a key:
But none of that should matter in the case of Qubes. You were implicitly trusting the old signing key. The “new” (a matter of terminology whether “new” or “extended”) signing key doesn’t include third-party signatures. It’s the same key fingerprint, and this is sufficient to verify.
This, however, is an issue for non-Qubes advanced users who want to initially bootstrap the signing key through the OpenPGP Web of Trust when attempting to establish a trust path to the key.
The above sentence requires a lot of background knowledge mentioned above at number [1] to make sense. If an advanced user with knowledge of the OpenPGP Web of Trust is affected, they can open a separate forum thread.
Yet another way for Qubes users to completely ignore avoid any key issues: Get on Qubes R4.3 + Qubes-Whonix 18.