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.
- Tips for Optimizing Linux Memory Usage
- Picking Out the Nouns
- "No Reboot" Kernel Patching - And Why You Should Care
- DevOps: Better Than the Sum of Its Parts
- Return of the Mac
- Android Candy: Intercoms
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Non-Linux FOSS: .NET?
- Consent That Goes Both Ways