Here's a quick hack for generating a very secure passphrase using GnuPG itself. The passphrase will not be easy to remember or type, but it will be very secure. The hack generates 16 random binary bytes using GnuPG then converts them to base64, again using GnuPG. The final sed command strips out the headers leaving a single line that can be used as a passphrase:
gpg --gen-random 1 16 | gpg --enarmor | sed -n 5p
Instead of using gzip to compress tarballs, use GnuPG. The tarballs will end up being about the same size, but they also will be encrypted. By the way, don't bother trying to gzip or otherwise compress any encrypted files. Encrypted data is usually incompressible. This is because data compression and encryption are closely related mathematically. Because of this, most cryptosystems, GnuPG included, automatically compress before encryption. There is also a slight gain in security by compressing.
You will be prompted for a passphrase twice, just like when encrypting before:
tar -cf - these files here | gpg -c > these-files-here.tgp
To extract the files, enter the password entered above:
gpg < these-files-here.tgp | tar -xvf -
If you want to use GnuPG in a script and don't want to be prompted for the passphrase, put the passphrase in a file called passphrase.txt, and use this to encrypt:
[$ cat passphrase.txt | gpg --passphrase-fd 0 -c < filename.txt > filename.gpg
Note: decrypting is nearly identical, simply drop the -c and switch the files around:
$ cat passphrase.txt | gpg --passphrase-fd 0 < filename.gpg > filename.txt
If you're going to e-mail the encrypted file, perhaps for off-site backup, add the -a option to turn on ASCII armor. The net effect is the same thing as --enarmor used earlier, but it includes encryption. This also produces smaller files than uuencoding or MIME, because by default, GnuPG compresses data before encryption.
To finish off the hack, we also mail the encrypted file at the same time. Note the use of -o - to force GnuPG's output to stdout:
$ cat passphrase.txt | gpg --passphrase-fd 0 -ac -o - filename.txt | mail firstname.lastname@example.org
By the way, putting the passphrase in a file can be extremely dangerous. Anyone who obtains a copy of that passphrase file can then decrypt any file it has ever encrypted. Someone even could create new files with the same passphrase, resulting in secure and undetectable forgery. Make sure your passphrase file, indeed the entire computer, has the security you expect.
Automating tasks inherently requires cutting humans out of the loop, so this security weakness is difficult to avoid. However, GnuPG can help even here by using public key encryption.
Do you have an OpenPGP-encrypted file, but no key ring and no idea what to do with it? Perhaps someone sent you an encrypted file and assumed you would know what to do. Maybe he or she doesn't know what to do either.
If the file has either a .pgp or .gpg extension, you can try decrypting it with GnuPG. Also, check the file with a text editor to see if it contains something like this:
-----BEGIN PGP MESSAGE----- Version: GnuPG v1.2.5 (GNU/Linux) jA0EAwMCwg21r1fAW+5gyS0KR/bkeI8qPwwQo/NOaFL2LMXEYZEV9E7PBLjjGm7Y DGG4QnWD5HSNOvdaqXg= =j5Jy -----END PGP MESSAGE-----
If it does, it's an ASCII-armored PGP-encrypted file.
This particular file is a real encrypted file containing the same value as used in the --print-md examples above and is encrypted with a passphrase of the same value.
Simply running GnuPG on an unknown file produces some useful information. If it prompts you for a passphrase, you'll need to get (or guess) the passphrase used to encrypt the file:
If it's not an OpenPGP file, you'll get something like this:
gpg: no valid OpenPGP data found. gpg: processing message failed: eof
If you get something else, however, maybe the file is encrypted with a public key that you don't have. The file also could be corrupted. A common mistake is to send binary files through e-mail or FTP transfer in ASCII mode.
GnuPG has a special diagnostic option to help troubleshoot these problems. The OpenPGP message format is internally formatted as packets; the --list-packets option dumps out information about those packets:
gpg --list-packets unknown_file.gpg
In addition to the standard information, this option also prints the full key ID of the public key that the file is encrypted with, if any, and what algorithms were used. It could be that the file was encrypted with a PGP 2.x public, sometimes called a legacy key. PGP 2.x predates the OpenPGP standard, so the standard GnuPG cannot decrypt it. Most PGP implementations made in the past several years are usually OpenPGP-compatible, so merely asking the sender to generate a compatible OpenPGP-encrypted file should do the trick.
There also are several different cryptographic algorithms supported by OpenPGP. Most have only some of these algorithms implementationally. Use gpg --version to see what might be missing.
Details on the packet format, such as the internal algorithm numbers, can be found in the OpenPGP standard RFC 2440.
Table 2. A short list of GnuPG options mentioned in the article.
|Short Option||Long Option||Description|
|--version||Version and algorithm information|
|-a||--armor||Turn on ASCII encoding when encrypting|
|--enarmor||Input binary, output ASCII|
|--dearmor||Input ASCII, output binary|
|--print-md HASH||Print a message digest using the specified HASH|
|-c||--symmetric||Conventional symmetric encryption with a passphrase|
|-o||--output||Specify a particular output file, use - for stdout|
GnuPG mostly uses long command-line options, but some options also have short single-letter options from the original PGP. For example, -v is --verbose, not --version.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- Home Automation with Raspberry Pi
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- KDE Reveals Plasma Mobile
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development