Decrypting a signature w/o verifying?

Hello,

I struggle to decrypt a signature made by a private key for which I have the public counterpart. Kleopatra or gpg always thinks ahead and tries to verify the signed file instead.

As I’ve learnt, a signature (a detached one in this case) contains an encrypted hash of the signed file. I’d like to see the hash and the content of the decrypted signature itself and then compare hashes myself by other means.

The public key is “openSUSE Project Signing Key opensuse@opensuse.org”, 22C07BA534178CD02EFE22AAB88B2FD43DBDC284 available at pgpkeys.eu (SKS+Honeypuck-based synchronizing keyservers network).

The detached signature is available here: https://download.opensuse.org/distribution/leap/15.4/iso/openSUSE-Leap-15.4-DVD-x86_64-Build243.2-Media.iso.sha256.asc

When I copy the *.asc content from a text editor to Kleopatra Notepad window and click “Decrypt / Verify Notepad”, I get "Decryption failed: No Data. Please see attachment.

Then I tried to decrypt it straight with RSA online: https://8gwifi.org/RSAFunctionality?keysize=2048
So I copied the message content located in between headers:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

-----END PGP SIGNATURE-----
…from the signature to the “ClearText Message Window” on the web site.

Then I exported the public key to *.asc file from Kleopatra and copied the RSA key located in between headers:
-----BEGIN PGP PUBLIC KEY BLOCK-----

-----END PGP PUBLIC KEY BLOCK-----
…to “Public Key” window on the web site in between headers:
-----BEGIN PUBLIC KEY-----

-----END PUBLIC KEY-----
But got an error.

I also tried to copy the RSA key to “Private Key” window on the web site in between headers:
-----BEGIN RSA PRIVATE KEY-----

-----END RSA PRIVATE KEY-----
…and switch from “Encrypt to RSA Encryption” radio button to “Decrypt RSA Message”. Unfortunatelly I got another error.

In the errors, there was a line “unable to decode base64 string” so it occured to me to try to decode the encrypted message in the signature file in a base64 decoder here: https://www.base64decode.org
Unfortunatelly after hitting “DECODE” I got a garbled text with lot of “white squares” characters: https://www.fileformat.info/info/unicode/char/25a1/index.htm

What am I doing wrong? Is it even possible to do what I on a whim set out to do?

Thanks.

gpg.log (4.6 KB)

Check the error when encrypting with RSA.

Encrypting with RSA.PNG

Check the error when decrypting with RSA.

Decrypting with RSA.PNG

Check the output when decoding from Base64.

Decoding from Base64.PNG

OK, I’ve looked into the issue a bit more and concluded what I wanted to do is not possible.

According to the OpenPGP RFC, a signature doesn’t have a native text form, it’s binary:
https://www.rfc-editor.org/rfc/rfc4880.html#section-2.4

Moreover, when signature is made into a text form w/ --armor option of gpg, which is the case of the openSUSE project detached signature, this conversion is irreversible:
https://www.rfc-editor.org/rfc/rfc4880.html#section-7

These facts explain the white squares I got when decoding from Base64. And even if I would be able to successfully decrypt the signature I’d only get a series o 0s and 1s.

At least, I was able to get as close as possible to the data of the signature by running:
gpg --list-packet openSUSE-Leap-15.4-DVD-x86_64-Build243.2-Media.iso.sha256.asc
…and then consulting the meaning of the output w/ the RFC again:
https://www.rfc-editor.org/rfc/rfc4880.html#section-5.2.2
https://www.rfc-editor.org/rfc/rfc4880.html#section-9.1
https://www.rfc-editor.org/rfc/rfc4880.html#section-9.4

Hi David,

it seems you are on the right track with your research in to the RFC4880.
In the end of course the signature has a binary hash in the OpenPGP dataformat.

Maybe an additional “-v” helps you to see more

gpg -v --list-packets openSUSE-Leap-15.4-DVD-x86_64-Build243.2-Media.iso.sha256.asc
gpg: ASCII-Hülle: Version: GnuPG v1.0.7 (GNU/Linux)

off=0 ctb=89 tag=2 hlen=3 plen=277

:signature packet: algo 1, keyid B88B2FD43DBDC284
version 3, created 1653770832, md5len 5, sigclass 0x00
digest algo 8, begin of digest 0b 53
data: 7890A162BA6715B818353C0258662445D5D7B32D4247568D19AA9015DF32F20840C9228F2C4BB6C01B395A02BFA9C9DC2F370433951A627AFB8328838D42DE3687403CD441052107322A931753060A45ACEC6035122E441EEEDB8D8AA978DD0B5AAB4B6302B3D73C56C1680BF25CA2C106CB7083CF2C5CAB9C57B8F76548148718C6EEF0A34EE9C53472F15BF8F81A97DB293314CA6F56F97767331AF958B35874D2851CC64EE167099ED2C8F01DB537D2D1A38B3167C9E83FC9E06C61BAC0D794616A038C4E697BD7E5AEFF27A83E8DBECF5BBED959B6DE26B7C3A69BE48A17D44DD2637B2D0C304DC166AE2083ED4B430D540A20B73F681B976011A3641021

(Your use case is not something I understand, as this is a signature for a sha256 hash file, so the hash of the hash file does not seem to matter much, does it?)

Regards,
Bernhard