Signing a GPG Public Key

Question

I am trying to manually create a GPG Public Key (see here). I am able to generate a GPG Public Key with a correct hash, but fail to RSA-sign that hash in a way that is accepted by the GPG CLI. For the GPG Public Key I have created see here.

To sign the hash I am using a private key on a PKCS#11 HSM. The HSM supports various signing mechanisms. I have tried signing with RSA-PKCS-PSS (with hash algorithm SHA512 and mask generation function MGF1-SHA512), SHA512-RSA-PKCS, and SHA512-RSA-PKCS-PSS, but neither produces a signature that the import command of the GPG CLI accepts. I suppose the GPG CLI expects a different padding.

Unfortunately, RFC 4880 does not explicitely cover GPG Public Key signature padding, but only specifies that EME-PKCS1-v1_5 and EMSA-PKCS1-v1_5 functions are used for PKCS#1 encoding. A quick search through the GPG source code shows that both PKCS#1 v1.5 and PSS are used at some points.

Does anybody know what padding exactly is supported in the import command of the GPG CLI?

Answer 1

You're barking up the wrong tree.

To answer the stated question, OpenPGP doesn't support or use RSA-PSS, at least not yet. For RSA signature, EMSA-PKCS1-v1_5 from PKCS1, referenced as rfc3447 (which republished PKCS1v2.1) and actually copied for your convenience into rfc4880 13.1.3 (though without the precomputed DigestInfo encodings), is the hash and padding together. Other PGP signature algorithms don't use padding (or only trivially). And it's not just the CLI; PGP protocols and formats are the same for all modes of GPG.

But your padding is fine; it's the hash that's wrong. In your posted message-and-decode, the signature given is a valid v1_5 signature for the SHA512 hash 89 6e e3 83 f0 24 e7 ba 4e 12 87 36 bd dd 55 fb 1d 8e 20 b0 f2 72 c6 3c e3 53 29 23 47 41 28 c9 b7 f4 51 ea 39 cd 1c ae ee 29 c2 e4 d4 13 fb 05 dd 89 bd 6b f7 20 76 63 95 f5 f8 b7 79 b2 d1 1b -- or to be exact, since the v1_5 signature scheme includes hashing, it is the signature for data with that SHA512 hash. However, as shown in your previous Q&A, the correct hash for this publickey is 2f 9b ad fd 89 90 e9 34 f3 15 c6 9c c5 8e 45 12 47 29 fe ab e6 18 a2 e2 71 fb bf e1 9e 20 10 8a 86 ea d9 dd 5b 87 58 87 45 85 98 2a 68 14 e9 e2 ef 9e b6 07 12 1d 9b 7c 15 8f 58 79 c2 92 c5 e9. The former value is in fact the SHA512 hash of the latter, aka the hash of the hash. Probably you have given the hash value as data to a signing mechanism that both hashes and signs its input -- as v1_5 signature implementations usually do, so they can ensure the same hash is applied to the data as is encoded in the DigestInfo. In particular a mechanism named 'SHA512-RSA-PKCS' almost certainly applies the hash (SHA512) AND pads and modexps the result.

To fix your actual problem, you should give the data not the hash as input to the signing mechanism, and not change anything relating to padding in any way.