0

I was thinking of using gpg4win to encrypt files I'll upload to cloud storage services. I already use 7-zip so if I just wanted to password protect my files I could have easily done it, but I wanted to implement TLS style asymmetric encryption for my files so that one has to acquire both the private key file and the password protecting it to decrypt the files on cloud.

Kleopatra (GUI client of gpg4win) has an option to import keys in PKCS12 (.p12 or .pfx) format and public certificate (.crt) format as well as its own OpenPGP Private Key (.asc) format. So I wanted to see if I can use .pfx keys created somewhere else to encrypt/decrypt files using Kleopatra. This test worked out well without any problem using .pfx file, but something unintuitive happened when I tried the same test using .crt public certificate file with no private key information. When I imported public certificate file which technically shouldn't hold any secret key components, encrypting and decrypting files on Kleopatra still worked with no problem. But from my understanding of how asymmetric RSA encryption works, encrypting files with a public certificate should work but decrypting process requires at least the corresponding private exponent field to calculate the symmetric key back.

rem 1. Creating public certificate using openssl
openssl req -x509 -key private.key -out public.crt -sha256 -set_serial 0 -days 365000

rem 2. Creating certificate + secret key bundle as .pfx
openssl pkcs12 -export -in public.crt -inkey private.key -out combined.pfx

The above code shows how I created a public certificate file without secret key components. I used -set_serial 0 to make sure even if I create certificates later on using the same private key it will still work on Kleopatra, because Kleopatra considers certificates with different serial numbers to be different despite being created from the same secret key. The version of Kleopatra is 4.0.0 and it's using GnuPG 2.3.4 and Libgcrypt 1.9.4.

To sum up my question is: Why does RSA decryption work on Kleopatra without any secret key components?

6
  • "I wanted to implement TLS style asymmetric encryption" - TLS does not use asymmetric encryption. It uses symmetric encryption instead after a key exchange. And this key exchange requires bidirectional communication, which means that doing things similar to TLS is not a useful approach in your case. Feb 5 at 5:31
  • 1
    The above code shows how I created a public certificate file without secret key components." - it doesn't. The private key is clearly created (private.key) and also included in the pfx file. Feb 5 at 5:40
  • @Steffen Ullrich Does the public.crt I created in step 1 include private key? I imported that public.crt which clearly doesn't have private components to Kleopatra and both encryption and decryption worked. I thought I explained that well enough in the question but in case I didn't that's what I meant. And yes I already know .pfx already containes private key and certificate information. Feb 5 at 8:26
  • When using the crt - Did you start with a fresh setup to make sure that the information from the previously imported PFX are no longer imported? Because it contained the cert and also private key already. Feb 5 at 8:30
  • Oh as in from Kleopatra I have to clear the previously cached private key information? I assumed when you delete private key it would not store the information anymore. I am aware of password by default cached for a few minutes unless you change it but I didn't see a reason why Kleopatra would want to do the same for private keys.. Feb 5 at 8:39

1 Answer 1

1

I found the reason for this problem and figured out sort of a workaround for this version (gpg4win 4.0.0). This problem seems to happen because Gpg4win caches any p12(.pfx) files it has previously used inside %appdata%\gnupg directory in some sort of encrypted forms, but never clears them even when you delete those private keys from Kleopatra.

enter image description here

So deleting your private key imported from a .pfx file as seen above will not be enough because the cached private key will still remain in %appdata%\gnupg directory and as long as it does, one can simply import public certificate (.crt) to Kleopatra and they can still decrypt all the files you encrypted with the .pfx key.

enter image description here

So my workaround was to delete files inside the folder private-keys-v1.d. The folder name maybe different but I assume the cache will always be inside a folder whose name starts with private-keys-. They seem to be the cached copies of previously imported .pfx keys and after these were cleared the problem mentioned in my question disappeared. If you open any of the cached files, unfortunately there is not enough information to recognize which private key the cache file corresponds to except for date & time when it was imported. As long as you keep copies of your .p12(.pfx) file somewhere safe and load it to Kleopatra only when you need to encrypt/decrypt, I suggest clearing out that cache folder every time you delete private keys from Kleopatra.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.