Super User is a question and answer site for computer enthusiasts and power users. It only takes a minute to sign up.
Sign up to join this community
I created an encrypted file with symmetric encryption.
gpg -c 50GBfile
Now I want to delete the original. Before I delete the original, I want to verify the integrity of the encrypted file. (Similar to the way ZIP files use CRC). Does gpg offer a way to verify the contents of symmetrically encrypted files?
If you encrypted the file with gpg -c, then there is no way to verify what the file contains without knowing the passphrase. That's a core property of symmetric encryption. Since you'll need to provide the passphrase anyway, do the real test: decompress the file and compare it with the original. On Linux or other unix variant:
gpg -d <50GBfile.gpg | cmp - 50GBfile
If you want an additional guarantee of integrity, you can sign the file with your private key by adding the -s option when you encrypt the file.
gpg -c -s 50GBfile
Then you can verify the signature with gpg --verify 50GBfile.gpg. Note that this only gives the guarantee that the file is one of the files that you've signed, this doesn't protect you against a mistake whereby you signed the wrong file.
If you used asymmetric encryption (with the public key of the recipient — your own public key), then verifying that the file has the desired content would require the recipient's private key. With multiple recipients, any recipient's private key would do. Usually you would put your own key as a recipient of all encrypted messages, with encrypt-to or hidden-encrypt-to in the GPG configuration file.
The only "verify" operation in gnupg is signature verification, which basically encrypts the hash of the encrypted file with a public key (=sign).
In my opinion this means that if the output bits are corrupted while the file is being encrypted, the hash will be calculated against the corrupted file. You will never discover this by verifying the signature of that file since you signed an already corrupted file.
It appears the only way to positively verify an encrypted file against corruption is to go through the lengthy process of decrypting the generated file and compare its hash with the original.
And this is what Sepero offered above, but instead of "You could verify..." it should be "The only way to verify..."
Update - to drive the point home:
A few minutes ago I did just that: Splitting a 9.8GB back-up file into 5 rar pieces, and each piece symmetrically encrypted by gnupg. Before deleting the rar pieces, I verified the integrity of the encrypted pieces as I discussed above: 1 out of the 5 did not pass the hash test. I decrypted again that piece, and now the decrypted piece's hash did match the original rar piece.
I binary compared the bad decrypted rar part with the good decrypted one, and the only difference in those 2GB files was one byte: C8 vs. 48 - which is caused by a 1 bit flip (i.e. 11001000 vs 01001000).
The moral of the story is that if, on a good WIN7 system and a good HDD, gnupg can flip a bit on decryption, it could do that on encryption too. I will never skip again this integrity verification step.
You could verify it by extraction and comparing the md5sum to the original.
$ gpg -d 50GBfile | md5sum
gpg: AES256 encrypted data
gpg: gpg-agent is not available in this session
gpg: encrypted with 1 passphrase
1df1aaffb20c5255e282d6f584489993 -
$ md5sum 50GBfile
1df1aaffb20c5255e282d6f584489993 50GBfile
In case you want to verify the integrity you need to sign the original file as well.
gpg --encrypt --sign file
Finally you can verify the integrity (based on the signature) by decrypting the file (integrity is checked automatically)
gpg --decrypt file.asc
