Environment: HP laptop with Windows XP SP2
I had created some encrypted files using GnuPG (gpg) for Windows. Yesterday, my hard disk failed so I had reimage the hard disk. I have now reinstalled gpg and regenerated my keys using the same passphrase as earlier. But, I am now unable to decrypt the files. I get the following error:
C:\sureshr>gpg -a c:\sureshr\work\passwords.gpg
gpg: encrypted with 1024-bit ELG-E key, ID 279AB302, created 2008-07-21
"Suresh Ramaswamy (AAA) BBB"
gpg: decryption failed: secret key not available
C:\sureshr>gpg --list-keys
C:/Documents and Settings/sureshr/Application Data/gnupg\pubring.gpg
--------------------------------------------------------------------
pub 1024D/80059241 2008-07-21
uid Suresh Ramaswamy (AAA) BBB
sub 1024g/279AB302 2008-07-21
AAA = gpg comment
BBB = my email address
I am sure that I am using the correct passphrase. What exactly does this error mean? How do I tell gpg where to find my secret key?
Thanks,
Suresh
This question is related to
windows-xp
gnu
gnupg
The resolution to this problem for me, was to notify the sender that he did use the Public key that I sent them but rather someone elses. You should see the key that they used. Tell them to use the correct one.
Yes, your secret key appears to be missing. Without it, you will not be able to decrypt the files.
Do you have the key backed up somewhere?
Re-creating the keys, whether you use the same passphrase or not, will not work. Each key pair is unique.
when reimporting your keys from the old keyring, you need to specify the command:
gpg --allow-secret-key-import --import <keyring>
otherwise it will only import the public keys, not the private keys.
One more cause for the "secret key not available" message: GPG version mismatch.
Practical example: I had been using GPG v1.4. Switching packaging systems, the MacPorts supplied gpg was removed, and revealed another gpg binary in the path, this one version 2.0. For decryption, it was unable to locate the secret key and gave this very error. For encryption, it complained about an unusable public key. However, gpg -k and -K both listed valid keys, which was the cause of major confusion.
Yes, your secret key appears to be missing. Without it, you will not be able to decrypt the files.
Do you have the key backed up somewhere?
Re-creating the keys, whether you use the same passphrase or not, will not work. Each key pair is unique.
when reimporting your keys from the old keyring, you need to specify the command:
gpg --allow-secret-key-import --import <keyring>
otherwise it will only import the public keys, not the private keys.
The resolution to this problem for me, was to notify the sender that he did use the Public key that I sent them but rather someone elses. You should see the key that they used. Tell them to use the correct one.
You need to import not only your secret key, but also the corresponding public key, or you'll get this error.
Yes, your secret key appears to be missing. Without it, you will not be able to decrypt the files.
Do you have the key backed up somewhere?
Re-creating the keys, whether you use the same passphrase or not, will not work. Each key pair is unique.
One more cause for the "secret key not available" message: GPG version mismatch.
Practical example: I had been using GPG v1.4. Switching packaging systems, the MacPorts supplied gpg was removed, and revealed another gpg binary in the path, this one version 2.0. For decryption, it was unable to locate the secret key and gave this very error. For encryption, it complained about an unusable public key. However, gpg -k and -K both listed valid keys, which was the cause of major confusion.
Yes, your secret key appears to be missing. Without it, you will not be able to decrypt the files.
Do you have the key backed up somewhere?
Re-creating the keys, whether you use the same passphrase or not, will not work. Each key pair is unique.
when reimporting your keys from the old keyring, you need to specify the command:
gpg --allow-secret-key-import --import <keyring>
otherwise it will only import the public keys, not the private keys.
workmad3 is apparently out of date, at least for current gpg, as the --allow-secret-key-import is now obsolete and does nothing.
What happened to me was that I failed to export properly. Just doing gpg --export is not adequate, as it only exports the public keys. When exporting keys, you have to do
gpg --export-secret-keys >keyfile
You need to import not only your secret key, but also the corresponding public key, or you'll get this error.
workmad3 is apparently out of date, at least for current gpg, as the --allow-secret-key-import is now obsolete and does nothing.
What happened to me was that I failed to export properly. Just doing gpg --export is not adequate, as it only exports the public keys. When exporting keys, you have to do
gpg --export-secret-keys >keyfile
Source: Stackoverflow.com