Although not OpenSSL's strength, it also can encrypt files. The flexibility of OpenSSL makes it a bit more complicated than GnuPG.
OpenSSL has very few defaults, so more options have to be used. There are also many algorithms from which to choose. Some algorithms, like DES and RC4-40, are kept only for backward compatibility and shouldn't be used anymore. Strong algorithms you should use include bf, which is the Blowfish algorithm, and -aes-128-cbc, which is the US NIST Advanced Encryption Standard (AES) with 128-bit keys running in Cipher Block Chaining (CBC) mode.
Here is an example:
$ openssl enc -aes-128-cbc < filename > filename.aes-128-cbc enter aes-128-cbc encryption password: Verifying - enter aes-128-cbc encryption password:
As with GnuPG, OpenSSL asks for a passphrase twice, which will not echo to the screen.
Decryption is also a bit more complicated:
$ openssl enc -d -aes-128-cbc -in filename.aes-128-cbc > filename enter aes-128-cbc decryption password:
Note the -d in this example, which specifies decryption.
OpenSSL, unlike GnuPG, does not automatically detect the file type or even what algorithm, key length and mode were used to encrypt a file. You need to keep track of that yourself. In my example, I've put that information in the filename extension. OpenSSL won't manage the files and file extensions for you, you have to specify where you want the outgoing data written.
If you don't specify the correct algorithm, OpenSSL either may spew garbage or complain about a bad magic number. Either way, without the correct options, your data won't decrypt properly. To be fair, this is simply not something OpenSSL was designed to do, but it does work.
Before we go much further, we should discuss the importance of passphrases. In most cryptosystems, the passphrase is the secret that keeps the other secrets. It's usually the weakest point. So, creating strong passphrases is important, but it's also difficult, unless you have the right tools. Using OpenSSL, you can create a strong passphrase quickly.
A simple guide to passphrases is that longer is usually better, and eight characters is not long enough (Table 1). The goal is to make a secret that you can remember but that someone else won't know, can't guess or won't eventually stumble upon.
Table 1. Password and passphrase strengths compared with estimated time to crack. Note: time to crack is very rough. Your crackage may vary.
|Type||Bytes||Characters||Bits/Character||Total Bits||Time to Crack|
|Base64 [A-Za-z0-9+/=]||6||8||6||48||Minutes to hours|
|Diceware Passphrase||8 words||12.9 per word||120||Uncrackable?|
OpenSSL can create very strong random passphrases like this:
$ openssl rand 15 -base64 wGcwstkb8Er0g6w1+Dm+
If you run this example, your output will be different from the example, because the passphrase is randomly generated.
The first argument of 15 is the number of binary bytes to generate, and the second argument of -base64 specifies that those binary bytes should be encoded in base64 characters. For 15 bytes, the output always will be 20 characters, plus a newline character.
The base64 character set consists only of uppercase and lowercase letters A–Z, the numbers 1–9 and the three punctuation characters: plus, slash and equals. This is intentionally a limited character set, but more complexity in the character set is not necessarily better. Adding only one additional character makes up for the difference in security. For example, an eight-character fully printable ASCII password is about a strong as a nine-character base64 password.
Although not as quick as using OpenSSL rand, the Diceware passphrase generator produces strong and often easy-to-memorize passphrases. I highly recommend it.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space