New answers tagged gnupg
I just found a blog post, which seems to be answering this question with a bash script. http://scruss.com/blog/2013/05/12/clean-up-your-gnupg-keyring/
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 ...
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
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
This happens when gpg-agent doesn't know which TTY to prompt on, which is happening here because you are redirecting stdin. You can put export GPG_TTY=$(tty) in your ~/.bashrc to setup the TTY for each login shell. The docs on gpg-agent has more details.
It's up to the PGP implementation which key it will use. I think that GPG will select the latest key and encrypt with only that key. The gateway application that we have developed will encrypt with both keys. Although I understand your thinking of having two separate keys, it does not really give you a lot of extra protection. Lets assume that all email ...
1) In order not to have problems with the first line, make sure to kill all your script instances when (re)testing. e.g. killall <scriptname>. 2) Add the --batch parameter to your gpg command. Everything else should fine. Hope this helps.
Try using ssh -v (or -vvv) and watch the order the ssh keys are tried. If id_rsa comes first something went wrong with your ssh_config. Try using ssh -i /path/to/id_lynx If this works check your ssh_config for IdentityFile <- should be a fully specified path, IdentitiesOnly yes man 5 ssh_config says: IdentitiesOnly Specifies that ssh(1) ...
Top 50 recent answers are included