1

My home computer consists of a VMWare host running Linux Mint, and a number of VMWare clients.

I run backups every night that compress my VHDs to a removable hard drive.

I'd like to encrypt the compressed images. And I'd like to do so without including a password in my backup scripts.

I have several removable disks that I rotate through, and I take one to work, everyday, so I have an offsite copy. And I include a copy of my backup scripts on each backup disk, to make it easier for me to figure out what I need to do to do a restore.

My thought is that if I used public-key encryption, I could encrypt with the public key, and require the private key to decrypt, and then the backup scripts could run without needing a password.

(I'd keep either the private key, or the passphrase to the private key file, in my KeePass database, which I also write to my backup media.)

But the thing is - I'd want to run this self-contained, so I could decrypt the backups using nothing other than what was written to the backup disks. That is, if I use gpg, I would want a copy of gpg on the backup disks, that I could run by itself, without having to install or configure anything. (That is, no dependencies on ~/.gpgconf, etc.)

And I've not been able to figure out how to do this, using gpg. The manuals seem to assume that you're going to install and configure it for your current user, and I need to be able to run it when nothing of the sort has happened.

Any ideas on how to:

  • Run gpg in an uninstalled mode, or
  • how to do this using some other tool? (openssl?)

Added comments...

Why can I not just install gpg?

The problem is doing a restore.

Suppose I have a complete system failure, perhaps my house burned down and everything was destroyed.

So I'm starting a restore with a new computer, bare drives, and my most recent off-site backups.

What do I do?

I boot some version of Linux that can mount ext4 partitions off of a thumb drive, and start putting things back together.

I can't depend upon anything other than the basic system utilities and what I've put on the backup disks.

  • 4
    Note: asymmetric encryption is not used to encrypt data, the amount that can be encrypted is limited to less than the key size and orders of magnitude slower than symmetric encryption. What is done is to encrypt the data with symmetric encryption such as AES and encrypt the symmetric key with asymmetric encryption. Essentially this is what gig does. Also note that an asymmetric or reasonable security will have a length of about 2048-bits (RSA) (which would be about 512 hex characters which is unwieldy to enter by hand.) – zaph Jan 14 at 18:52
  • And, of course, my backups would be far longer than any reasonable RSA key size. – Jeff Dege Jan 14 at 19:14
  • Remember, though, that these are scripted processes. I could have the script generate a symmetric key, use it to encrypt the VHD, then encrypt it with a public key and write it to the removable disk. – Jeff Dege Jan 14 at 19:16
  • Why not just install gpg and some keys? You must trust the decrypting system, otherwise why put your decrypted backups there? Maybe a secure ssh connection to the backup system is another idea – Xen2050 Jan 15 at 0:04
  • See my added comments – Jeff Dege Jan 15 at 4:45
0

I've been playing around with this problem, and I think I have an approach.

First, one time, before doing backups:

Generate an RSA key-pair:

$ openssl genpkey -out backupkey.pem -aes-256-cbc -algorithm rsa
.................++
............................++
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
$ 

Use a good pass phrase - not something that anyone is going to hack. Six-to-eight random words works well. Don't pick quotations out of favorite books or songs.

Next, extract your new public key from the .pem file you just created:

$ openssl rsa -in backupkey.pem -pubout -out backupkey.key
Enter pass phrase for backupkey.pem:
writing RSA key
$ ls -l backupkey.*
-rw-r--r-- 1 jdege jdege  800 Jan 15 20:26 backupkey.key
-rw-r--r-- 1 jdege jdege 3418 Jan 15 20:16 backupkey.pem
$ 

Save these somewhere, you'll be using them on every backup. I store them with my backup scripts, and put copies in my KeePass password database.

Then, on each backup

Generate a random session key:

$ openssl rand -hex 128 > session.key
$

Then, run your backup, making the encryption of the result the last step in your pipeline:

$ generate-my-backup.sh |
> gzip |
> openssl enc -aes-256-cbc -pass file:./session.key -out /mnt/backups/20190115/backup.bup.gz.enc
$ 

Next, encrypt the session key with the public RSA key, delete the session key, and copy the encrypted session key to your backup media:

$ openssl rsautl -encrypt -inkey backupkey.key -pubin -in session.key -out session.key.enc
$ cp session.key.enc /mnt/backups/20190115/
$ rm session.key
$ 

And copy the file containing your private key to your backup media:

$ cp backupkey.pem /mnt/backups/20190115/
$ 

If you have to restore

It's simple, if you know the passphrase to your private key:

$ openssl rsautl -decrypt -inkey backupkey.pem  -in session.key.enc |
> openssl enc -d -aes-256-cbc -in backup.bup.gz.enc -pass stdin |
> gunzip |
> restore-my-backup.sh
Enter pass phrase for backupkey.pem:
$

We're running "openssl rsautl" to decrypt the encrypted session key to stdout, and then we're running "openssl enc -d" to decrypt the backupfile, reading its key from stdin, and writing the output to stdout, so it can be passed to whatever else of the pipeline is necessary to put the file where it belongs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.