Tag Info

New answers tagged

0

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/


2

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 ...


0

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


1

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


0

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.


1

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

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.


1

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