I have a directory with multiple .gpg files, all encrypted with the same passphrase. How can I decrypt them all without entering the passphrase over and over?
How to decrypt multiple files in a directory with gpg
gpg
Related Solutions
I'm using this script:
#!/bin/sh
TAPE="/dev/nst0"
mt-st -f $TAPE setblk 0
mt-st -f $TAPE status
totalsize=$(du -csb . | tail -1 | cut -f1)
tar cf - . | \
gpg --encrypt --recipient target@key.here --compress-algo none | \
pipemeter -s $totalsize -a -b 256K -l | \
mbuffer -m 3G -P 95% -s 256k -f -o $TAPE \
-A "echo next tape; mt-st -f $TAPE eject ; read a < /dev/tty"
To adapt it for your needs, here are the main points:
tar
reads from the current directory and outputs tostdout
. This way tar doesn't deal with changing tapes or encryption.gpg
has compression switched off as this slows the process considerably (100MB/sec+ down to 5MB/sec)pipemeter
is used to monitor the process and give an estimated time until all the data has been written to tape - this can be removed if it is not neededmbuffer
buffers the data into memory - this example uses a 3GB buffer, adjust as needed - to allow the tape drive to run for longer before running out of data, reducing "shoe shining" of the tape.- The
-A
option ofmbuffer
handles multiple tapes by ejecting a tape once the end has been reached and waiting for theEnter
key to be pressed after the next tape has been loaded. This is where your/root/advancetape
script can go.
One issue to be aware of when using this with LTO tapes:
- The tape block size is set to variable, and
mbuffer
writes in 256k blocks. This works well for me with an LTO3 drive, howevertar
likes to use a different block size. This, combined with the fact thatmbuffer
handles the spanning across tapes rather thantar
, means you will need to read the data off the tape again throughmbuffer
and then pass it throughgpg
and on totar
. If you try to extract it directly off the tape withtar
(even if you skipped encryption) it will likely not work, and will certainly break once it reaches the end of the first tape, without giving you a chance to change to the next tape.
You do not want a symmetric cipher
If you need to auto-run encryption you don't want to use a symmetric cipher with a passphrase (this is what gpg -ac does). Storing the passphrase in a script or in cron is unacceptable and pointless (seriously, this sounds harsh, but you may as well rot13 it.)
If you're using encryption, it isn't enough to simply "change the permissions" of the script. If it was, you could simple change the permissions on the data you want to hide. Encryption at this level is obviously meant to stop someone who has gained access to your account (most likely maliciously) reading the data once they have access.
In this case, what you want is public key crytography. You generate a private key (which is encrypted again with a symmetric cipher with a password) and a public key. The public key can be distributed anywhere. Anyone can encrypt data that you can read with your private key. Noone should have access to your private key. So for the type of encryption you need, it's perfect. You can store your public key on the server and encrypt all of your data using it. If an attacker has your public key and your encrypted data, he can do nothing.
Your private key should be the bit of the puzzle a potential attacker is always missing. You need to hide this. i.e. encrypting data that you can read is easy. Decrypting it should be hard. With a symmetric cipher, the difficulty of both is the same (if you want to think of it in those terms, it's probably not the greatest analogy.)
GPG makes public crypto relatively painless, but first things first, you need to generate a keypair (this is not done on your server, but on your desktop or somewhere secure you're happy having your private key):
$ gpg --gen-key
Run through the questions there.
Then you want to export your GPG public key and copy and paste it to your server:
$ gpg --list-keys
$ gpg --armor --export me@mydomain.com > pub.key
Copy pub.key to your server and then import with:
$ gpg --import pub.key
If you're considering using encryption in the first place, it's obviously because you've got sensitive data. I'd stress again: you need to think seriously about the way you're encrypting this data as it is a whole lot of effort for no gain if you simply use a symmetric cipher where the password can be accessed trivially.
Best Answer
It seems like this does the trick: