Encrypting files with gpg
 

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 :eek: when :eek: you :eek: need :eek: it :eek: 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.

Take a look at dmcrypt / luks. I will claim that it's the de-facto standard for encryption on Linux and offers just as much protection as gpg.

AFAIK, AES (not ASE) only supports a maximum of 256-bit key. ccrypt and 7zip use AES-256 by default. Cryptsetup and Veracrypt have it available. If it has to be gpg, try using the '--symmetric' option and choose AES256.
https://en.wikipedia.org/wiki/Advanc...ption_Standard

Seems to be more about encrypting an entire FS. Im just looking for a way to encrypt a file by itself and keep the keys away from the file as much as possible.

Sorry, the ASE was a typo. I was referring to AES, which is apparently available at 256 for a max.
So still confused, because when I ran the --gen-key command, it allowed me to pick RSA 4096, so I guess I don't know what the difference is between an RSA encryption and an AES encryption...

My biggest issue so far is how to be able to encrypt without having to actually send the file anywhere... At most, I would want to copy the file to external USB drive once encrypted.

To encrypt FILENAME with symetric key PASSPHRASE:
Then to decrypt:

No you can also use it to set up a crypto container as said before...

If you are dealing with "[legal] requirements from upstairs," then I suggest that you research what are the best-practices and/or the legal strictures which apply to your application. I suggest also that you prepare a design-document and a testing-plan and that you send this "upstairs" for explicit approval before you begin.

Basically, the attorneys are going to have to review it, and they're going to look at "the entire shinola," not just the choice of cipher-algorithm.

I have encountered several web-sites built by "competent little companies" which had elaborate home-grown encryption strategies built into their site. But, those strategies didn't meet the requirements of US laws such as (e.g.) Sarbanes-Oxeley and/or HIPAA. As a result, the sites were scrapped, and the little-companies who had built them lost their only star client. (But: the "star client" didn't have any choice.)

Well-accepted encryption frameworks, such as GPG, OpenSSL, ipsec (VPN), and so-on, will always be preferred over "home-grown" implementations of a particular cipher. Security, especially crypto security, is a process that must protect the weakest link in the entire, complex chain.

gpg is not capable of sending email. You should use the --recipient option with yourself as the recipient. No email will be sent.

RSA is a public key encryption scheme, while AES is symmetric.

Gnupg can used to encrypt using:

1) asymmetric cryptography (Public/private key) (RSA/Elgamel)

2) symmetric cryptography (AES, CAST5, CAMELLIA, TWOFISH)

3) Both of above.

As manu-tm said you should use option 2 above to encrypt. It would just need a password and you have to remember or note it down or use a password vault. And it's also the fastest.

To encrypt:
To decrypt:

That's good news. I was under the impression that it was sending it to a email address, but if that's just the address of the KEY, then my problem may be solved.

I don't think symmetric is the way to go. Your choice of gpg is good. Create a recipient asymmetric key pair for each db that you want to back up. The encrypting system will have all the public keys on its keyring. The private key copies will be maintained by whoever is responsible for that db. That way even if your system is hacked, the encrypted data is still safe. Key management is an important part of the system.

Huh? You have been told precisely that in posts 4, 7, 10 and 20 (especially in post 7) of this thread.

Don't get me wrong, I mean no offense, but I do want to point out that when people here take the time to answer your questions you should actually take the time to read their answers...

That's a good idea. They may want more than just encryption (such as adding a MAC or signature), and they may have restrictions on key use and distribution. So, definitely check with them. AES256 as an algorithm should be good enough for encrypting tho, I mean the NSA uses it for top secret data, it's just they may want more than just encryption.