Is Qubes master signing key SHA1?

[19hundreds]

Hello,

this is not a bug report but a heads up. I've read the guideline and I couldn't find a better fitting way to report this case. Somehow mailing list felt wrong.

I'm definitely a newbie in everything therefore, hopefully, what I'm reporting here is totally irrelevant if not wrong.

I'm studying GPG and I was playing around with GPG conf.

Some guides I've stumbled upon are advising to add this GPG line to gpg.conf

weak-digest SHA1

because of this reported SHA1 collision.

After adding this like I noticed that I was unable to import Qubes signing key

user@x-vault:~
> gpg --batch --gen-key foo
gpg: keybox '/home/user/.gnupg/pubring.kbx' created
gpg: Generating a default key
gpg: /home/user/.gnupg/trustdb.gpg: trustdb created
gpg: key 0x05E61DD6D9F8311C marked as ultimately trusted
gpg: revocation certificate stored as '/home/user/.gnupg/openpgp-revocs.d/80F8CC94DC3432176C8FCE7705E61DD6D9F8311C.rev'
gpg: done

user@x-vault:~
> gpg --import qubes-master-signing-key.asc 
gpg: Note: signatures using the SHA1 algorithm are rejected
gpg: key 0xDDFA1A3E36879494: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 1
gpg:           w/o user IDs: 1

Notice the: gpg: Note: signatures using the SHA1 algorithm are rejected.

The key was not imported.

user@x-vault:~
> gpg -k
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
/home/user/.gnupg/pubring.kbx
-----------------------------
pub   rsa4096/0x05E61DD6D9F8311C 2018-10-06 [SC]
      Key fingerprint = 80F8 CC94 DC34 3217 6C8F  CE77 05E6 1DD6 D9F8 311C
uid                   [ultimate] Joe Tester <joe@foo.bar>

The only way I have found to import it was to use the --allow-non-selfsigned-uid option:

user@x-vault:~
> gpg --allow-non-selfsigned-uid --import qubes-master-signing-key.asc 
gpg: Note: signatures using the SHA1 algorithm are rejected
gpg: key 0xDDFA1A3E36879494: accepted non self-signed user ID "Qubes Master Signing Key"
gpg: key 0xDDFA1A3E36879494: public key "Qubes Master Signing Key" imported
gpg: Total number processed: 1
gpg:               imported: 1

user@x-vault:~
> gpg -k
/home/user/.gnupg/pubring.kbx
-----------------------------
pub   rsa4096/0x05E61DD6D9F8311C 2018-10-06 [SC]
      Key fingerprint = 80F8 CC94 DC34 3217 6C8F  CE77 05E6 1DD6 D9F8 311C
uid                   [ultimate] Joe Tester <joe@foo.bar>

gpg: Note: signatures using the SHA1 algorithm are rejected
pub   rsa4096/0xDDFA1A3E36879494 2010-04-01 [SCEA]
      Key fingerprint = 427F 11FD 0FAA 4B08 0123  F01C DDFA 1A3E 3687 9494
uid                   [ unknown] Qubes Master Signing Key

So I commented the weak-digest SHA1 line from my GPG conf and repeated the operation. It worked without problems.

Then I checked your key with this command:

user@x-vault:~
> gpg --list-packets qubes-master-signing-key.asc 
# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
    version 4, algo 1, created 1270124793, expires 0
    pkey[0]: [4096 bits]
    pkey[1]: [17 bits]
    keyid: DDFA1A3E36879494
# off=528 ctb=b4 tag=13 hlen=2 plen=24
:user ID packet: "Qubes Master Signing Key"
# off=554 ctb=89 tag=2 hlen=3 plen=568
:signature packet: algo 1, keyid DDFA1A3E36879494
    version 4, created 1270124793, md5len 0, sigclass 0x13
    digest algo 2, begin of digest d7 b9
    hashed subpkt 2 len 4 (sig created 2010-04-01)
    hashed subpkt 27 len 1 (key flags: 03)
    hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
    hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
    hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
    hashed subpkt 30 len 1 (features: 01)
    hashed subpkt 23 len 1 (keyserver preferences: 80)
    subpkt 16 len 8 (issuer key ID DDFA1A3E36879494)
    data: [4095 bits]

Accordingly to RFC 4880 SHA1 is ID 2

Hash Algorithms
ID           Algorithm                        Text Name
1          - MD5 [HAC]                      "MD5"
2          - SHA-1 [FIPS180]             "SHA1"

which matches the line:

digest algo 2, begin of digest d7 b9

My limited knowledge doesn't help here, however I interpret the above output in this way:

you signed your public key (MD5 hashed) using a SHA1 hashed signature

:public key packet:
    version 4, algo 1, created 1270124793, expires 0

:signature packet: algo 1, keyid DDFA1A3E36879494
    version 4, created 1270124793, md5len 0, sigclass 0x13
    digest algo 2, begin of digest d7 b9

Do I get it right?

Do you think this can be an issue?

I hope I'm not wasting your precious and already limited time. Thank you very much for your exceptional work: words can't describe my appreciation.

[andrewdavidwong]

This appears to be a duplicate of #1116 or #2818 or both. If so, please comment on the appropriate existing issue instead. If you believe this is not really a duplicate, please leave a comment briefly explaining why. We'll be happy to take another look and, if appropriate, reopen this issue. Thank you.

[marmarek]

:public key packet: version 4, algo 1, created 1270124793, expires 0

This is public key packet, so this table applies: RSA

digest algo 2, begin of digest d7 b9

Yes, self-signature indeed use SHA1.

In general, it may be a good idea to create new signature using SHA256 or such, to ease the use with weak-digest SHA1 option enabled. But in practice, in the current state SHA1 problems doesn't affect security of the key itself, because there are no known pre-image attacks. New signatures are made with SHA256 hash function.

[19hundreds]

@andrewdavidwong yes the two tickets are related to this one. The difference is that, to my understanding, there is a potential security risk. I've no way to doubt @marmarek who says that there is no known pre-image attack so, yes, I guess it should be closed.

@marmarek out of curiosity, how one can be reasonably sure that there is no successful pre-image attack after an hash function has been found vulnerable?

[marmarek]

We could ask the same question about any hash function - we don't know what attack exists until the research is made public. As for public knowledge, the only attack currently possible (but still requiring enormous resources) is generating two files with the same hash (collision attack). But not generating input matching predefined hash value (pre-image attack).

[andrewdavidwong]

yes the two tickets are related to this one. The difference is that, to my understanding, there is a potential security risk.

That is not a difference, since the other two issues also entail security risks. There is a security risk to using SHA-1 instead of SHA-256 or SHA-512 for PGP signatures (#1116), and there is a security risk to not generating a new QMSK, given the limitations of the current one (#2818).

[19hundreds]

@andrewdavidwong & @marmarek thank you. You gave me a lot of inputs!