key confusion

I create a certificate and from another machine encrypted a file using the public key.
I was then able to decrypt the file on my local machine using the passphrase.

Then I deleted the certificate, created a new one and used the same passphrase. (This was meant to replace the original Certificate/keys).

On the other machine, I encrypted another file using the old public key and was able to open it on my machine. Not sure why since the certificate was removed. I had restarted Kleopatra and the running agent.

On the other machine, I put the new public key in place and encrypted a third file.

On my local machine, I deleted the new certificate and imported the old certificate. I restarted everything and was still able to decrypt the third file which used the new public key although I had the old certificate installed in Kleopatra.

Am I missing something.

Thanks.

When you deleted the certificate, did you also delete the private key?

No I did not.

I do not see how you delete the private key associated with the certificate.

It does not seem to be an option in the certificate deletion steps.

Can you elabotate?

Thanks for the replay.

It’s been a while since I’ve used Kleopatra. I usually use the command line. I did not see an option to specifically delete private keys either. A check with command line revealed that deleting the cert. with Kleo should erase both keys.

I am at a loss as to why your machine is still able to decrypt the files. Sorry. Perhaps someone else has some ideas?

Regards,
Sean C.

P.S.
In case you’re interested: to check for private keys with the command line, type:

gpg -K

(Note: Use lower case “k” for public keys, upper case for private.)

To delete private keys, you must first delete the public key:

gpg --delete-keys [key ID]

…and then the private key:

gpg --delete-secret-keys [key ID]

Hi Sean C.

Thanks for the help.

I list the public and private keys from the commandline.

I do have the certificate for the one causing the problem installed in Kleopatra.

In trying to determine what was the [key ID] in the output, I had to search the Net for help.

I then deleted the cert that I had created.

When listing the public and private keys, they indeed have been deleted.

At this point, I think i am going to try this all over again.

I’m wondering if it is some bug with Kleopatra.

Thanks,

Eric

OK, so I made this real simple.

I deleted all certificates from Kleopatra and made sure there were no keys in the public or private keyrings (gpg2 -k and gpg2 -K).

I created a new certificate and export the public key to ASCII armored file.

Put that public key on another machine and used a .NET app we wrote (not Kleopatra) to encrypt a file using the public key.

Then I delete my certificate in Kleopatra on my machine and ensure there are no public or private keys.

I even reboot to make sure none of the agents in memory are caching anything.

I then am able to decrypt the file using the passphrase successfully.

I’m using Windows and right clicking on the file then choosing “Decrypt and Verify”.

It starts Keopatra in the background to do the Decryption as expected

If I close Kleopatra and decrypt the file again, it does not challenge me for the passphrase as expected.

One of the running daemons must be caching it.

The other processes I see running are gpg-agent.exe, dbus-daemon.exe and scdaemon.exe.

When I kill those and decrypt the file again, it asks me for the passphrase.

My original problem had been deleting and creating a new cert and before replacing the public key in our .NET app on the other machine, I had it encrypt and send me a file again.

That file was decrypted and I had expected it to fail.

I replaced the public key in the .NET app on other machine and had it encrypt a file which I then decrypted on my machine successfully as expected.

Then I deleted the new certificate on my machine, imported the old one and was able to decrypt the new file encrypted with the second public key using the old cert (so it seemed).

Perhaps something had been cached in a daemon initially as i was not killing them between changing out certificates when I originally started this thread.

Now I just think the problem is that the original cert/private key are still being kept even after deleting them and killing all memory resident programs.

Not sure where the problem is here.

Anyone have a suggestion?

I mostly use Kleopatra rather than the command line. I have used Kleo to delete certificates and although no special option is shown for deleting private keys, when you select one of your own certificates to delete, a warning dialogue comes up which states that a private key will be deleted and asking for confirmation.
When I have used gpg -K on the command line to check whether deletion has occurred, I always found that Kleopatra had performed correctly. So I doubt that your problem is with a bug in Kleopatra.
Did you carry out your initial tests in a rather short period of time ? Could your mail client maybe have maintained a cached copy of the secret key for a short time ?

Hi Philip,

Not using email for this.

The .Net application was written by my supervisor and it encrypts a SQL server report file which is just a .csv file. Then it attaches the encrypted file to a normal email message and sends it to me.

I then save the attachment on my local machine where I have Kleopatra and that is when I Right Click on the file and Decrypt it.

So the mail client caching the secret key is not a possibility in this situation.

Thanks for you input.

This problem has been resolved.

The issue was that unknown to me my supervisor that wrote the .NET app that was encrypting the file used a method from a .NET DLL encryption library that let you specify the passphrase so that the recipient of the file did not need to have the private key to decrypt the file.

I had provided the supervisor with both the public key and the private key/passphrase as he was working over the weekend and need to be able to decrypt the files he was encrypting with his .NET code to verify the Application was working correctly.

Therefore he had the passphrase.

I got him to use a different method that did not take the passphrase.

We recompiled and then the app encrypted the file. I now fail to decrypt the file if the Certificate and private key are gone from my Kleopatra.

If I import the private the certificate and try again, I am challenged for the passphrase.

Upon entering the phrase the file decrypts successfully.

Nothing wrong with Kleopatra.

Sorry for wasting everyone’s time.

Thanks again Sean C. and Philip Jackson for your replies.

Eric

Glad to hear that you’ve solved the issue. Sounds like your supervisor should be recruited by the NSA.