GnuPG: Failure to import public key
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	• aheinecke
	Mar 5 2019, 11:43 AM

Description

Attached public key (which can be obtained from the Commerzbank website)

Maik Mnch.asc1 KBDownload

does not import in GnuPG because the self signature cannot be verified. It gives RSA verify -> Bad Signature.

According to the Armor comment it was exported by "OpenPGP totemomail"

Maybe it is just invalid but maybe it is just unusual and GnuPG could import it or even has a bug in the verification codepath for this key. I don't see anything unusual in the list packets output.

# off=0 ctb=99 tag=6 hlen=3 plen=269
:public key packet:
        version 4, algo 1, created 1539872646, expires 0
        pkey[0]: [2048 bits]
        pkey[1]: [17 bits]
        keyid: 03592E4F07D8F171
# off=272 ctb=b4 tag=13 hlen=2 plen=41
:user ID packet: "Maik M\xc3\xbcnch <maik.muench@commerzbank.com>"
# off=315 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid D401CC5E60627DAC
        version 4, created 1539872647, md5len 0, sigclass 0x13
        digest algo 8, begin of digest de c3
        hashed subpkt 2 len 4 (sig created 2018-10-18)
        subpkt 16 len 8 (issuer key ID D401CC5E60627DAC)
        data: [4094 bits]
# off=858 ctb=89 tag=2 hlen=3 plen=310
:signature packet: algo 1, keyid 03592E4F07D8F171
        version 4, created 1539872647, md5len 0, sigclass 0x13
        digest algo 8, begin of digest 70 2f
        hashed subpkt 2 len 4 (sig created 2018-10-18)
        hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
        hashed subpkt 21 len 3 (pref-hash-algos: 8 9 10)
        hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
        hashed subpkt 27 len 1 (key flags: 0F)
        hashed subpkt 9 len 4 (key expires after 3y0d0h0m)
        subpkt 16 len 8 (issuer key ID 03592E4F07D8F171)
        data: [2047 bits]

btw. Symantec OpenPGP Desktop imports it, but cannot use it afterwards.

I have this on "Needs Triage" because I just would like that maybe someone more knowledgeable in OpenPGP takes a quick look at this to see if there is anything unusual about this. I'm fine with "Invalid" Status if it's just a bad key.

Details

External Link: https://wald.intevation.org/forum/forum.php?thread_id=2033&forum_id=84&group_id=11
Version: STABLE-BRANCH-2-2

Event Timeline

• aheinecke created this task.Mar 5 2019, 11:43 AM

• werner claimed this task.Mar 5 2019, 6:22 PM

The creating software is broken in regard to non-ASCII characters in the UID:

The hashed data is

; pubkey
99 01 0d 04 5b c8 97 86  01 08 00 96 59 29 84 2f 
ca 9f 97 10 26 3f 48 21  e0 3e d5 98 3e f7 e2 63 
2b 3c 20 d6 63 fa b8 91  85 50 e9 d4 68 0b af 20 
87 4e 12 d2 a9 8b 99 fd  11 69 e1 b7 a8 94 cd ff 
ef 12 49 fe d8 9f 81 ab  9d 35 98 00 2b f9 6d 4d 
47 60 b2 27 ca 80 3d 08  60 ac 66 38 ac dc c2 99 
2d 82 ea 32 76 b5 61 4c  df de 4d a2 44 d3 32 b0 
e6 9c 4b e6 12 ab cc ce  e5 34 b3 82 e2 cd 85 00 
1d 64 98 bc bf 7b 59 63  20 9b f3 6c dc a5 3c f6 
54 45 94 e6 96 e3 af ac  ef 13 59 f3 8c ca b0 ea 
c4 4f 98 f4 05 cf 2d 9d  39 e2 c8 76 4a a4 0b 92 
74 6f 8f 09 96 3c 56 3d  e2 b8 d7 23 a1 a7 13 c1 
02 ef c6 2b eb 34 17 1d  3c 9f 17 01 92 3c 6a 7a 
1c a6 b9 be 62 03 8f 1c  2d f7 2d a9 40 86 29 4c 
03 ca 7d 57 11 9e de fd  53 00 1b c3 ad 53 fa 0e 
b4 38 b1 75 c8 20 f2 a3  c3 a0 5b fc 62 a6 30 5c 
b6 69 21 eb 1a 4f d7 76  6d 6d 1d 00 11 01 00 01 
; uid
b4 00 00 00 29 4d 61 69  6b 20 4d c3 bc 6e 63 68 
20 3c 6d 61 69 6b 2e 6d  75 65 6e 63 68 40 63 6f 
6d 6d 65 72 7a 62 61 6e  6b 2e 63 6f 6d 3e
; sig
04 13 01 08 00 20 05 02 5b c8 97 87  06 0b 09 08
07 03 02 04 15 08 09 0a 04 16 02 03  01 02 1b 0f
05 09 05 a3 9a 80
; magic
04 ff 00 00  00 26

which gives (grep -v \; | undump | sha256sum)

60179d1a507d6f783a70cbaa508daa286c6fe3e503f856be6ba083b12e53ccb0

But according to the signature it should give

702f46e4d1602f6e68c98fa3ca1597e080e7f37389b123c5bb36f09c88ab22ce

this can be achieved by changing the UID part to:

; uid
b4 00 00 00 28 4d 61 69  6b 20 4d fc 6e 63 68 
20 3c 6d 61 69 6b 2e 6d  75 65 6e 63 68 40 63 6f 
6d 6d 65 72 7a 62 61 6e  6b 2e 63 6f 6d 3e

So the fault of the creating software is that it created the UID
packet with the the UTF-8 encoding:

Maik M\xc2\bcnch

but hashed the Latin-1 encoding:

Maik M\xfcnch

For example PGP never had a consistent encoding model and used
input data for the user id verbatim (the standard requires
UTF-8). That is not a real problem because it was kind of
consistent. GPG has always used heuristics to _display_ PGP
created Latin-1 encoding in a correct way.

The software totemomail however is not consistent and thus the
signature is broken. Users of totemomail won't notice that
because it will for sure use the same code parts for signature
creation and verification.

Thank you very much for the analysis. I'll forward the info.

GnuPG: Failure to import public keyClosed, ResolvedPublicActions

Description

Details

Event Timeline

GnuPG: Failure to import public key
Closed, ResolvedPublic
Actions