Downloaded gpg, but somewhat confused about how to encrypt files for safekeeping.
Examples seem to include a "recipient" address but im not trying to email or send anything. Just want to encrypt file in-place and find a way to keep the keys safe somewhere. I was thinking about printing the key and keeping it in a safe, is this the best approach?
I don't want to keep the keys online, for fear that someone will be able to hack in and swipe my data and keys.

Does the manual help?

And yes, putting the passphrase into a save will be safer compared to storing it online.

Not really, unless im just not reading things correctly.
I don't have a "recipient" as shows in the doc.

alice gpg --output doc.gpg --encrypt --recipient blake@cyb.org doc

Im just trying to encrypt a file locally for safekeeping, I don't want it sent anywhere or exposded on the internet.

I have never used gpg for that purpose, but reading e.g. this article it looks to me that it can be done.
The way I understand it the recipient needs to be specified to tell gpg whose private key should be able to decrypt the file. I your case, this would be your own, so you need to specify yourself as the recipient. Does that make sense?

In case you are not tied to actually using gpg there are other ways I personally find more convenient.

- ecryptfs-utils is the standard Ubuntu tool that allows you to set up a private directory.
- Truecrypt allows you to use a crypto container
- You can also create a crypto container with dmcrypt or luks.

The last is my personal preference as it feels like the most "native" approach in Linux that requires minimal dependencies... but that's obviously highly subjective. Let me know if I should elaborate a bit more on these alternatives...

you normally do not use it all by it's self

pgp is "built into" things

like your desktop !!!

in kde and Gnome on the r-click menu is NORMALLY !!! a option "to encrypt" something

or built into your mail client

Thanks everyone, I really don't want to send it to myself. It's a database backup/dump which I want to encrypt to make sure it's not going to be readable by anyone who doesn't have the keys. Since it's a backup, it's purpose is to just hang-around and be available if it's needed.
I had read that 'gpg' offered the best security, which is the big concern here since the data contains sensitive customer personal data.

You are not actually "sending" it to yourself, you are just specifying yourself as the recipient. That said, I thing I have a compelling argument why in your usecase this is not the way to go.

You create the dump that contains the critical data. While doing that, the dump is written to disk ... unencrypted. You then encrypt it. However, the original, unencrypted data still lies on your disk. (Just deleting it is insufficient) Someone with forensic tools & knowledge might still be able to recover that data. To prevent that, you'd have to "shred" it, i.e. overwriting it with random data.

A crypto container would allow you to avoid this problem. The procedure would be this:
Open crypto container
Dump the file into the container
Close the crypto container.

Does that make sense?

Im actually going to use named-pipes for the dump, piping the data through gzip as well as gpg before landing the data. The local filesystem doesn't have enough room to hold the dump uncompressed, much-less 2 copies of if which I would need if I did the steps serially.

It sounds like you are trying to encrypt a large amount of data. I recommend NOT using gpg for this, because public key encryption is very slow. Instead, use cryptsetup, ccrypt, veracrypt, or 7zip with password.

Ok, I see. I am not sure about the implications of this approach concerning data that may or may not end up anywhere in unencrypted form, but using pipes at least sounds like it could cirumvent this problem. (If the data was really critical, I personally still would feel safer with the container approach, but that's your call)

Which brings us back to your original question.
So have you tried setting yourself as the recipient? I just tested this with a simple text file and it worked without any issues.

There you go. Another reason. :-)

Because of legal ramifications, I will only be allowed to use strong encryption, nothing like zipping files with passwords will pass muster from upstairs.
They are ok with GPG, im just trying to figure it out. The time isn't really a big factor, it's only about 20-30gb, and the time won't be a concern.
Im open to alternatives, as long as I can use something with serious encryption. We have to meet several ISO standards (which I don't really know anything about), but I was told GPG would be acceptable as long as it's a 4K key or 512ASE or something like that.

gpg doesn't use public key encryption for the whole file:

Frankly, it seems to me that this person is trying to re-invent a wheel. The best course of action is to find an existing backup/archive utility which, as a matter of course, encrypts its backup volumes.

Basically, "the name of the game," in a situation like this, is simply to make it "less than trivially easy" "bothersomely difficult" for anyone who swiped your disk-drive at airport security to make any practical use of his purloined goodies ... while also making sure that you won't be permanently locked-out of your own files.

"Generally speaking," IMHO, "the second consideration is far more important than the first."

Lots (and lots and lots...) of times, encryption is simply a defense against "crimes of opportunity." Someone steals a laptop at Starbuck's. You can't get the laptop back, but you want to be sure that the data on the machine is inaccessible. You presume that the b*stard person who stole the machine isn't an employee or agent of "a 'three-letter acronym' government agency" ... and, let's face it, (unless you have far more serious troubles than encryption can help you with ...) he isn't.

Really, the most important consideration ought to be ... to make sure that you can actually use your backup when you need it most!

I have kept trying to be minimal in my details, because I didn't want to get hung-up on them in the forum, but it seems like im failing.

We have a database application which runs at a datacenter. It's about 20-30Gb in size, and I can hold a single dump in the available on-host storage. We don't have a SAN, but do have an external storage device, to be used for offsite backups. It's attached via USB to the host.

The goal was to "as cheaply as possible" perform a database dump and take that dump offsite, which is where the encryption comes in. By exposing the drive to being shipped, we are at risk, and business doesn't want to take that risk, so they want to encrypt the data before shipping.

My goal is to use existing freeware where possible, which precludes fancy backup tools/software. The database itself already provides a dump capability, so by piping that to a gzip and a gpg we hoped to be able to keep a few copies on an external drive which we can swap-out periodically to our office for offsite backup.

The keys to the encryption need to be kept safe as it's not acceptable to have the decryption key anywhere near the drive itself when it's offiste. As for testing, we do a DBCC prior to the backup, so we have good expectation that the backup is viable. That said, we are not actually running a DBCC on the backup itself, which would be the only sure way to know it's gold.

To try and get back to my original question, is there a way to use gpg without actualyl having to send the file via internet/email? It's not practical to send the dump file of that size accross the network. Since we backup weekly, im not concerned about the time for the gzip/gpg operation, it can take several hours overnite without being an issue.