Unable to verify encrypted file signature

encryptiongnupg

Using Kleopatra, I have geneated two sets of keys to sign and encrypt a file:

Set A:
- Public key : PA
- Private Key : PRA
Set B:
- Public key : PB
- Private Key : PRB

I have used (PA) of Set A and for signature, (PRB) in Set B. This process executed successfully and generated an encrypted file.

However, when trying to verify the signature and decrypt/verify the files with Kleopatra, I get the following results:

The file was decrypted but not validated the signature.

test.text.asc –>test.txt: Not enough information to check signature validity.

Signed on 2012-03-23 07:49 by test@test.com (Key ID :xxxxxxx).
The validity of the signature cannot be verified.

What’s wrong? Please advise if I am missing any settings.

Best Answer

It seems you don't have the public key of Set B (PB) in your keyring of Set A. Thus, gnupg won't be able to know if it was really a good signature from that key. Without you having PB, the signature will just "look like" it has been signed by the key with the key id of 0xXXXXXXXX, but it lacks the PB to check it thoroughly.

You might encounter this issue with Kleopatra, and the solution is to set the trust of the public key before verifying. Even if you have the correct public key for the signed file/message, the response from the application will show as not valid unless the public key is trusted.

Finding the File for a Detached Signature

gpg will automatically verify detached signatures against the same file name, without .asc or .sig enxtension. From man gpg:

--verify
  Assume  that  the first argument is a signed file or a detached signature and
  verify it without generating any output. With  no  arguments,  the  signature
  packet  is  read from STDIN. If only a sigfile is given, it may be a complete
  signature or a detached signature, in which case the signed stuff is expected
  in a file without the ".sig" or ".asc" extension.  With more than 1 argument,
  the first should be a detached signature and  the  remaining  files  are  the
  signed  stuff.  To  read  the  signed stuff from STDIN, use '-' as the second
  filename.  For security reasons a detached signature cannot read  the  signed
  material from STDIN without denoting it in the above way.

Thus, gpg --verify package_name.asc expects the signed file to be available as package_name. If it isn't (or at another location), also give the path to this file:

gpg --verify detached_siganture.asc signed_file

Is it the Right File?

OpenPGP does not expect the file name (or any other identifier) to be stored in the signature. But: the signature is the hash sum of the signed file, encrypted with the signer's private key, so it can be decrypted with his public key. If the decrypted hash sum does not match the one of the file used to verify against, you know the file isn't the same that was signed (but cannot tell whether it is the wrong file because of selecting the wrong, or it was tampered).

Linux – Set up gpg to decrypt own local files without supplying passphrase

By default, each system user has his own home directory and thus own GnuPG home directory. In each GnuPG home directory, you can store an individual replica of a secret key.

If no passphrase is required, it seems the key is not encrypted with one. Export the key (gpg --export-secret-keys [key-id], and import it for the other user (to his own GnuPG home directory, gpg --import) who should have to enter a passphrase. Now edit the key (gpg --edit-key [key-id]) and add a passphrase (passwd inside the GnuPG edit shell).

The other user will have to enter the passphrase to access his copy of the key. As he has no privileges to access opsacc's unencrypted version without a passphrase, he will not be able to decrypt files without the passphrase.

But be aware, once he has the passphrase, he can of course easily remove it.

Best Answer

Related Solutions

How are detached signatures used to verify a file’s integrity and authenticity

Finding the File for a Detached Signature

Is it the Right File?

Linux – Set up gpg to decrypt own local files without supplying passphrase

Related Question