Gpg: BAD signature from "Qubes OS Release 4 Signing Key" [full]

User Support
1

Joey Goodnews is back with another poser.
Dowloaded the iso from:
https:–mirrors.edge.kernel.org/qubes/iso/Qubes-R4.0.3-x86_64.iso
and the associated hashes and gpg signatures. Then checked the security of the file.
NOTE: (https:-- substituted for https:// to allow hyperlinks to be included in the post)
The short story is the gpg signatures, installs and iso verification went as hoped, but the verification of the Digests failed.
I apparently dropped a stitch somewhere and would appreciate any insights. Thanks
The screen output of the gpg session follows:

tmp01@temp$ sudo gpg2 --fetch-keys https:–keys.qubes-os.org/keys/qubes-master-signing-key.asc
gpg: requesting key from ‘https:–keys.qubes-os.org/keys/qubes-master-signing-key.asc’
gpg: key DDFA1A3E36879494: public key “Qubes Master Signing Key” imported
gpg: Total number processed: 1
gpg: imported: 1

tmp01@temp$ sudo gpg2 --edit-key 0x36879494
gpg (GnuPG) 2.2.23; Copyright © 2020 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: starting migration from earlier GnuPG versions
gpg: porting secret keys from ‘/root/.gnupg/secring.gpg’ to gpg-agent
gpg: migration succeeded

pub rsa4096/DDFA1A3E36879494
created: 2010-04-01 expires: never usage: SC
trust: unknown validity: unknown
[ unknown] (1). Qubes Master Signing Key

gpg> fpr
pub rsa4096/DDFA1A3E36879494 2010-04-01 Qubes Master Signing Key
Primary key fingerprint: 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494

gpg> trust
pub rsa4096/DDFA1A3E36879494
created: 2010-04-01 expires: never usage: SC
trust: unknown validity: unknown
[ unknown] (1). Qubes Master Signing Key

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
Do you really want to set this key to ultimate trust? (y/N) y

pub rsa4096/DDFA1A3E36879494
created: 2010-04-01 expires: never usage: SC
trust: ultimate validity: unknown
[ unknown] (1). Qubes Master Signing Key
Please note that the shown key validity is not necessarily correct
unless you restart the program.

gpg> q

tmp01@temp$ sudo gpg2 --keyserver-options no-self-sigs-only,no-import-clean --fetch-keys https:–keys.qubes-os.org/keys/qubes-release-4-signing-key.asc
gpg: requesting key from ‘https:–keys.qubes-os.org/keys/qubes-release-4-signing-key.asc’
gpg: key 1848792F9E2795E9: public key “Qubes OS Release 4 Signing Key” imported
gpg: Total number processed: 1
gpg: imported: 1
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 1 signed: 1 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1 valid: 1 signed: 0 trust: 1-, 0q, 0n, 0m, 0f, 0u

tmp01@temp$ sudo gpg2 --check-signatures "Qubes OS Release 4 Signing Key"
pub rsa4096 2017-03-06 [SC]
5817A4…
uid [ full ] Qubes OS Release 4 Signing Key
sig!3 18487… 2017-03-06 Qubes OS Release 4 Signing Key
sig! DDFA1A3E36879494 2017-03-08 Qubes Master Signing Key

gpg: 2 good signatures

tmp01@temp$ sudo gpg2 -v --verify Qubes-R4.0.3-x86_64.iso.asc Qubes-R4.0.3-x86_64.iso
gpg: Signature made Sun 19 Jan 2020 08:41:26 PM EST using RSA key 5817A4…
gpg: using pgp trust model
gpg: Good signature from “Qubes OS Release 4 Signing Key” [full]
gpg: binary signature, digest algorithm SHA256, key algorithm rsa4096

tmp01@temp$ sudo md5sum -c Qubes-R4.0.3-x86_64.iso.DIGESTS
Qubes-R4.0.3-x86_64.iso: OK
md5sum: WARNING: 23 lines are improperly formatted

tmp01@temp$ sudo sha1sum -c Qubes-R4.0.3-x86_64.iso.DIGESTS
Qubes-R4.0.3-x86_64.iso: OK
sha1sum: WARNING: 23 lines are improperly formatted

tmp01@temp$ sudo sha256sum -c Qubes-R4.0.3-x86_64.iso.DIGESTS
Qubes-R4.0.3-x86_64.iso: OK
sha256sum: WARNING: 23 lines are improperly formatted

tmp01@temp$ sudo sha512sum -c Qubes-R4.0.3-x86_64.iso.DIGESTS
Qubes-R4.0.3-x86_64.iso: OK
sha512sum: WARNING: 23 lines are improperly formatted

tmp01@temp$ sudo gpg2 -v --verify Qubes-R4.0.3-x86_64.iso.DIGESTS
gpg: armor header: Hash: SHA256
gpg: original file name=’’
gpg: Signature made Sun 19 Jan 2020 08:42:18 PM EST using RSA key 5817A4…
gpg: using pgp trust model
gpg: BAD signature from “Qubes OS Release 4 Signing Key” [full]
gpg: textmode signature, digest algorithm SHA256, key algorithm rsa4096

To verify, downloaded and installed master signing key from website:
https:–keys.qubes-os.org/keys/qubes-master-signing-key.asc

tmp01@temp$ sudo gpg2 --import ./qubes-master-signing-key.asc
gpg: key DDFA1A3E36879494: “Qubes Master Signing Key” not changed
gpg: Total number processed: 1
gpg: unchanged: 1

2

Joey Goodnews is back with another poser.
Dowloaded the iso from:
https:–mirrors.edge.kernel.org/qubes/iso/Qubes-R4.0.3-x86_64.iso
and the associated hashes and gpg signatures. Then checked the security of the file.
NOTE: (https:-- substituted for https:// to allow hyperlinks to be included in the post)
The short story is the gpg signatures, installs and iso verification went as hoped, but the verification of the Digests failed.

tmp01@temp$ sudo gpg2 -v --verify Qubes-R4.0.3-x86_64.iso.DIGESTS
gpg: armor header: Hash: SHA256
gpg: original file name=‘’
gpg: Signature made Sun 19 Jan 2020 08:42:18 PM EST using RSA key 5817A4…
gpg: using pgp trust model
gpg: BAD signature from “Qubes OS Release 4 Signing Key” [full]
gpg: textmode signature, digest algorithm SHA256, key algorithm rsa4096

Strange, because that process results in “Good signature” for me.
BAD signature suggests that the file is corrupt in some way.
The sha256sum of my file is :
c68053bccd4b5a046df52d489c68eb5f81067450ec9e739391ab5478b0311964 Qubes-R4.0.3-x86_64.iso.DIGESTS

Suggest you try downloading again.

1 Like
3

What is concerning is that the iso passed the hash tests.

4

It’s arguable that you shouldn’t have been doing those test until you
had a DIGESTS file that was verified.

Anyway, without being able to compare your file with a verified file
it’s hard to say what has happened. Blank space,line endings, who
knows?

5

I thought the same, but was just following the steps in the guide.

So here’s what further looking found:
Three different DIGESTS files were examined:
Qubes-R4.0.3-x86_64.iso.DIGESTS-1 (1st download)
Qubes-R4.0.3-x86_64.iso.DIGESTS-2 (2nd download)
Qubes-R4.0.3-x86_64.iso.DIGESTS-cp (copy/paste text from website to text file).
tmp01@temp$ diff Qubes-R4.0.3-x86_64.iso.DIGESTS Qubes-R4.0.3-x86_64.iso.DIGESTS-cp
24d23
<
tmp01@temp$ diff -s Qubes-R4.0.3-x86_64.iso.DIGESTS-2 Qubes-R4.0.3-x86_64.iso.DIGESTS-cp
4d3
<
Running sudo gpg2 -v --verify Qubes-R4.0.3-x86_64.iso.DIGESTS
substituting each of the files above resulted in DIGESTS-1 and DIGESTS-cp failing while DIGESTS-2 passed.

6

Correction: The command,
tmp01@temp$ diff Qubes-R4.0.3-x86_64.iso.DIGESTS Qubes-R4.0.3-x86_64.iso.DIGESTS-cp
24d23
<
Should have been:
tmp01@temp$ diff Qubes-R4.0.3-x86_64.iso.DIGESTS-1 Qubes-R4.0.3-x86_64.iso.DIGESTS-cp
24d23
<

7

I wish the NSA would quit messin’ with my downloads.

1 Like
8

But did this change make the verification work?

9

Not sure what you’re question is regarding, but the second download of the DIGESTS file did pass the signature check. I won’t pursue why the first download of the file had extra characters. Using the hashes from the second download of the DIGESTS file seems sufficient to deem the iso valid.

10

what does the nsa have to do with a bad download?

  1. when you do the gpg --verify cmd you are verifying the DIGESTS file has not been tampered. keep this in mind

  2. when you do the sha1/md5/etc cmds you are checking the ISO file hash against what is in the DIGESTS file.

  3. if the DIGESTS file has a good sig and sha256 hashes match what is in the DIGESTS file, only then can you say you have a good iso file that has been verified

you cant verify sigs if you are messing with the file.

you have not obtained the DIGESTS file correctly. if DIGEST-2 was a good sig, based on the diff you have against the DIGEST-CP, line 4 was deleted in your copy/paste. you will see there is 2 line breaks after the ‘Hash: SHA256’ line in the proper file. you are missing one.

how are you downloading the DIGESTS file? a simple wget should be all you need.

  1. wget the iso
  2. wget the DIGESTS
  3. verify the DIGESTS sig with gpg --verify
  4. verify the sha256sum of the iso matches what is in the DIGESTS
  5. install
1 Like
11

The hashes in the DIGESTS files were all the same. Running the *sum for SHA1, SHA256, SHA512 all verified the iso integrity. The concern was why did the verification of the DIGESTS file fail. diff showed there was a line or character difference when comparing the three DIGESTS files which did not apparently affect the hashes.
As mentioned in the reply to unman, the DIGESTS files ending in -1 and-2 were downloaded using the ‘Save As’ feature in firefox. The DIGESTS file ending in -cp was text copied/pasted from the website. Nothing was added/deleted from the files ending in -1 or -2. The file ending in -cp was a direct copy/paste using gvim to a text file.
DIGESTS-2 file passed the integrity verification and the hashes it contained verified the iso integrity which allowed the install to proceed.

The NSA quip could have easily been martians since both will probably have a hand in the upcoming elections.

12

gvim is locally configured with IDE bundles, multiple blank lines are stripped to one. That is likely happened when copy/pasting using gvim to create …DIGESTS-cp. However, less was used to inspect -1 and -2. -1 appears to have an extra line at the end of the file.
-2 was the goldylocks DIGESTS file.

13

@unman, @qubesnewb
Good challenges, Thanks for taking the time to respond.

14

Please use code blocks (preformatted text). This will make your post much easier to read, and you won’t have to do weird stuff like this. You can either use the buttons in the GUI editor or learn some Markdown syntax (which is a great skill to learn anyway).

That shouldn’t be concerning. Anyone can create a text file that contains valid Qubes ISO hash values. The hash values are public knowledge, so someone can simply copy/paste them into a file, add whatever else they like (perhaps hash values for malicious ISOs), then (clear)sign the whole file with their own PGP key.

In other words:
(1) If the ISO passes the hash tests, then the .DIGESTS file contains valid hash values. [If A, then C.]
(2) If the .DIGESTS file is authentic, then the .DIGESTS file contains valid hash values. [If B, then C.]

“If A, then B” does not logically follow from (1) and (2).

This is correct. When a text file is PGP clearsigned, the exact contents, character for character, is the content being signed. If the contents change even by one character (including spaces and line breaks), you should not expect signature verification to succeed.

Unfortunately, we don’t control the disposition of the .DIGESTS files on the Qubes website, since it’s hosted on GitHub pages. It would be better for .asc and .DIGEST files to be downloaded rather than display by the user’s browser by default. I’ll had some hover text instructing the user to save the file; maybe that’ll help a little.

It’s worth noting that you had already successfully verified the detached PGP signature on the ISO, so checking the hash values after that was superfluous (though I can understand the desire to do so, since it’s easy and can provide some extra peace of mind).

15

I was taking a quick look at this and it seems it is not possible to force the download on buttons (<a href=""></a>) due to the same-origin policy (downloaded file is in a different website than qubes-os.org/).

I’m not sure it will help much since most people when they see a button they just click it right away, but it’s better than nothing.

16

Yup.

Yup.

1 Like
17

@adw
The reason for the http:-- was the first attempt to post was kicked back with a notification that more than one link was not allowed in a post.
Also,

was in regard to the cautions found in:

“However, it is possible that an attacker replaced Qubes-RX-x86_64.iso with a malicious ISO, computed the hash values for that ISO, and replaced the values in Qubes-RX-x86_64.iso.DIGESTS with his own set of values. Therefore, ideally, we should also verify the authenticity of the listed hash values.”
At the time the DIGESTS file failed verification left the hashes in question, and further the iso validity.

18

All hashes SHOULD be the same. What would a failure of one hash, while the passing of the other hashes imply?

19

Yes, I wrote that section, and it’s consistent with what I said above: It shouldn’t be concerning that the ISO passed the hash tests. Anyone can create a file that has valid hashes for an authentic Qubes ISO, since those hash values are public knowledge.

If you have an authentic .DIGESTS file, and an ISO successfully checks against it, then it follows that the ISO must also be authentic. However, the converse does not hold: If you have an authentic ISO, and it successfully checks against a .DIGESTS file, it does not follow that the .DIGESTS file must also be authentic.

Each .DIGESTS file is simply a PGP-clearsigned text file that contains several different hash values output by several different cryptographic has functions: MD5, SHA-1, SHA-256, and SHA-512. Each hash value is on its own line, output by (and readable by) the corresponding standard GNU utilities: md5sum, sha1sum, sha256sum, and sha512sum. When you check one, say SHA-512, you compute the SHA-512 hash value of the ISO. The resultant value should match the SHA-512 value contained in the .DIGESTS file. The intention of including such a variety of hash values in each .DIGESTS file is to grant flexibility to users in selecting the hash function of their choice when verifying the ISO. It is neither necessary nor expected that users will verify every hash value separately, though there is no harm in doing so.

Some cryptographic hash functions are known to be weaker than others in certain ways. For example, MD5 is known to be vulnerable to collision attacks and is thought to be theoretically vulnerable to a preimage attack. Therefore, if the MD5 check were to succeed while the others failed, one might consider the possibility that the ISO had been replaced with a forgery with the same MD5 hash value. However, such an attack would seem to be highly impractical and unlikely at present. A more likely explanation for such an occurrence would be a hardware fault, e.g., data corruption in non-ECC memory, perhaps due to a solar proton event. At any rate, from a practical security perspective, it is easy to run such checks several times and, if an ISO fails to pass verification consistently, to re-download the appropriate files, possibly over a different connection and/or on a different machine.

20

Yet another reason to use preformatted text. They won’t be converted into hyperlinks.