The command-line tool executable is aptly named openssl on Unix, and openssl.exe on Windows. It has two modes of operation: interactive and batch. When the program is started without any options, it will enter interactive mode. When operating in interactive mode, a prompt is displayed indicating that it is ready to process your command. After each command is completed, the prompt is redisplayed, and it’s once again ready to process another command. The program can be exited by simply issuing the quit command. Commands entered in interactive mode are handled in precisely the same manner as if you’d entered them from the command line in batch mode; the only difference is that you don’t need to type “openssl” before each command. We’ll normally operate the tool in batch mode in our examples, but if you feel more comfortable using the interactive mode, that’s fine.

The first part of a command is the name of the command itself. It’s followed by any options that you wish to specify, each one separated by a space. Options normally begin with a hyphen and often require a parameter of their own, in which case the parameter is placed after a space.

Unless indicated otherwise, the order in which you specify options is not significant. There are only a small number of cases in which the order is significant, usually because a specific option must appear on the command line as the last option specified.

[ ca ]
default_ca      = CA_default            # The default ca section
 
####################################################################
[ CA_default ]
 
dir             = ./demoCA              # Where everything is kept
certs           = $dir/certs            # Where the issued certs are kept
crl_dir         = $dir/crl              # Where the issued crl are kept
database        = $dir/index.txt        # database index file
new_certs_dir   = $dir/newcerts         # default place for new certs
 
certificate     = $dir/cacert.pem       # The CA certificate
serial          = $dir/serial           # The current serial number
crl             = $dir/crl.pem          # The current CRL
private_key     = $dir/private/cakey.pem# The private key
RANDFILE        = $dir/private/.rand    # private random number file
 
x509_extensions = usr_cert              # The extentions to add to the cert
 
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crl_extensions        = crl_ext
 
default_days    = 365                   # how long to certify for
default_crl_days= 30                    # how long before next CRL
default_md      = md5                   # which md to use
preserve        = no                    # keep passed DN ordering
 
# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy          = policy_match

In Chapter 1, we introduced cryptographic hash functions, better known as message digest algorithms, which can be used for computing a checksum of a block of data. OpenSSL includes support for MD2, MD4, MD5, MDC2, SHA1 (sometimes called DSS1), and RIPEMD-160. SHA1 and RIPEMD-160 produce 160-bit hashes, and the others all produce 128-bit hashes. Unless you have a need for compatibility, we recommend that you use only SHA1 or RIPEMD-160. Both SHA1 and RIPEMD-160 provide excellent security for general-purpose use, but SHA1 is significantly more common. MD5 is a very popular message digest algorithm, but it does not have a good security margin for all applications. We discuss message digests in detail in Chapter 7.

OpenSSL handles SHA1 oddly. There are places where you must refer to it as DSS1 (the dgst command, described later), and there are places where you cannot refer to it as DSS1 (everywhere else). This is a limitation of the implementation. Use SHA1 as the name, unless we specifically mention that you need to use DSS1.

The command-line tool provides commands for using most of the supported algorithms. The dgst command is the main command for accessing message digests, but most of the algorithms can be accessed using a command of the same name as the algorithm. The exception is RIPEMD-160, which is named rmd160 .

When using the dgst command, the algorithm is specified using an option with the name of the algorithm, with the exception of RIPEMD-160, which also uses the name rmd160 for this interface. Regardless of the algorithm or form of the command, each of the algorithms accepts the same options to control how the command will function.

The default operation performed with any of the message digest commands is computing a hash for a block of data. That block of data can be read from stdin, or it can be one or more files. When more than one file is used, a separate hash is computed for each file. By default, the computed hash or hashes are written in hexadecimal format to stdout, unless an alternate output file is specified.

In addition to computing hashes, the message digest commands can also be used for signing and verifying signatures. When signing or verifying a signature, only one file should be used at a time; otherwise, the signatures will run together and end up being difficult to separate into a usable form. When signing, a signature is generated for the hash of the file to be signed. A private key is required to sign, and either RSA or DSA may be used. When you use a DSA private key, you must use the DSS1 message digest (even though it is the same as the SHA1 algorithm). You may use any algorithm other than DSS1 with an RSA private key. Verifying a signature is simply the reverse of signing. Normally, a public key is required to verify a signature, but a private key will work, too, because a public key can be derived from the private key, but not vice versa! When verifying a signature with an RSA key, public or private, you’ll also need to know which message digest algorithm was used to generate the signature.

OpenSSL supports a wide variety of symmetric ciphers. Of course, these ciphers are also available for use with the command-line tool. Many of the large number of ciphers are variations of a base cipher. The basic ciphers supported by the command-line tool are Blowfish, CAST5, DES, 3DES (Triple DES), IDEA, RC2, RC4, and RC5. Version 0.9.7 of OpenSSL adds support for AES. Most of the supported symmetric ciphers support a variety of different modes, including CBC, CFB, ECB, and OFB. For each cipher, the default mode is always CBC if a mode is not explicitly specified. Each of the supported symmetric ciphers and their various modes of operation are discussed in detail in Chapter 6. In particular, it is important to mention that you should generally never use ECB, because it is incredibly difficult to use securely.

The enc command is the main command for accessing symmetric ciphers, but each cipher can also be accessed using a command of the same name as the cipher. With the enc command, the cipher is specified using an option with the name of the cipher. Regardless of the cipher or form of the command that is used, each of the ciphers accepts the same options to control how the command will function. In addition to providing encryption and decryption of data with symmetric ciphers, the base64 command or option to the enc command can also be used for encoding and decoding of data in base64.

The default operation to be performed with any of the cipher commands is to encrypt or base64 encode the data. Normally, data is read from stdin and written to stdout, but input and output files may be specified. Only a single file can be encrypted, decrypted, base64 encoded, or base64 decoded at a time. When encrypting or decrypting, an option can be specified to perform base64 encoding after encryption or base64 decoding before decryption.

Each of the ciphers requires a key when encryption or decryption is performed. Recall from the brief discussion of symmetric ciphers in Chapter 1 that the key is what provides the security of a symmetric cipher. In contrast with traditional cryptographic techniques, modern cipher algorithms are widely available to be scrutinized by anyone that has the time and interest. The key used to encrypt data must be known only to you and the intended recipient or recipients of the encrypted data.

A password is often used to derive a key and initialization vector that will encrypt or decrypt the data. It is also possible to specify the key and initialization vector to be used explicitly, but supplying that information on your own is often prone to error. In addition, different ciphers have different key requirements, so supplying your own key requires in-depth knowledge of the particular cipher. The password can be specified with the pass option, according to the general guidelines for passwords and passphrases outlined later in this chapter. If no password or key information is specified, the tool will present a prompt to obtain it.

If you specify a password or passphrase to derive the key and initialization vector, the command-line tool uses a standard OpenSSL function to perform the task. Essentially, the password or passphrase that you specify is combined with a salt . The salt that is used in this case is simply eight random bytes. The MD5 hash of the combined salt and password or passphrase is then computed and broken into two parts, which are then used as the key and initialization vector.

The SSL protocol relies heavily on a variety of different cryptographic algorithms, including message digest algorithms, symmetric ciphers, and public key cryptography. Its use of most of these algorithms is generally done without the need for any human intervention. A common exception, though, is its use of public key cryptography. For example, in order for a server to employ the SSL protocol, it requires a private key and a certificate . The certificate contains the public key that matches the server’s private key. These keys must be created as part of the process for configuring the server to use SSL, and they are frequently not created automatically. Instead, they must be created by whoever is configuring the server.

SSL isn’t the only protocol that makes use of public key cryptography. Most modern software that supports encrypted communications uses it, too. Some of the more popular examples include SSH, PGP (Pretty Good Privacy), and S/MIME. All of these examples use public key cryptography in some form, and we’re overlooking many other applications as well. We discuss OpenSSL’s support for public key cryptography in detail in Chapter 8.

S/MIME is a competing standard to PGP (Pretty Good Privacy) for the secure exchange of email. It provides authentication and encryption of email messages using public key cryptography, as does PGP. One of the primary differences in the two standards is that S/MIME uses a public key infrastructure to establish trust, whereas PGP does not. Trust is established when there is some means of proving that someone with a public key is actually that person, and that the key belongs to that person.

PGP was written and released in 1991 by Phil Zimmermann. It quickly became the de facto standard for the secure exchange of information throughout the world. Today, PGP has become an open standard known as OpenPGP, and is documented in RFC 2440. Because PGP does not rely on a public key infrastructure to establish trust, it is easy to set up and use. Today, one of the most common methods of establishing trust is obtaining someone’s public key either from a key server or directly from that person, and manually verifying the key’s fingerprint by comparing it with the fingerprint information obtained directly from the key’s owner over some trusted medium, such as the telephone or paper mail. It is also possible to sign a public key, so if Alice trusts Bob’s key, and Bob has used his key to sign Charlie’s key, Alice knows that she can trust Charlie’s key if the signature matches Bob’s. PGP works for small groups of people, but it does not scale well.

S/MIME stands for Secure Multipurpose Internet Mail Exchange. RSA Security developed the initial version in 1995 in cooperation with several other software companies; the IETF developed Version 3. Like PGP, S/MIME also provides encryption and authentication services. A public key infrastructure is used as a means of establishing trust, which means that S/MIME is capable of scaling to support large groups of people. The downside is that it requires the use of a public key infrastructure, which means that it is slightly more difficult to set up than PGP because a certificate must be obtained from a Certification Authority that is trusted by anyone using the certificate to encrypt or verify communications. Public keys are exchanged in the form of X.509 certificates, which require a Certification Authority to issue certificates that can be used. Because a Certification Authority is involved in the exchange of public keys, trust can be established if the certificate that issued a certificate is trusted. Public key infrastructure is discussed in detail in Chapter 3.

S/MIME messages may have multiple recipients. For an encrypted message, the body of the message is encrypted using a symmetric cipher, and the key for the symmetric cipher is encrypted using the recipient’s public key. When multiple recipients are involved, the same symmetric key is used, but the key is encrypted using each recipient’s public key. For example, if Alice sends the same message to Bob and Charlie, two encrypted copies of the key for the symmetric cipher are included in the message. One copy is encrypted using Bob’s public key, and the other is encrypted using Charlie’s public key. To decrypt a message, the recipient’s certificate is required to determine which encrypted key to decrypt.

The command-line tool provides the smime command, which supports encryption, decryption, signing, and verifying S/MIME v2 messages (support for S/MIME v3 is limited and is not likely to work). Email applications that do not natively support S/MIME can often be made to support it by using the command-line tool’s smime command to process incoming and outgoing messages. The smime command does have some limitations, and it is not recommended in any kind of production environment. However, it provides a good foundation for building a more powerful and fully featured S/MIME implementation.

Many commands (particularly those that involve a private key) require a password or passphrase to complete successfully, usually to decrypt a key that is stored securely on a disk. Normally, the command-line tool will prompt you to enter a password or passphrase when appropriate, even if you’re not running the tool in interactive mode. The need for a password or passphrase to be physically entered by someone using the keyboard at the computer when it’s needed makes using the tool for automated processes difficult, to say the least.

Fortunately, there’s a solution. Many of the commands accept options that allow you to specify the necessary password or passphrase. Unfortunately, the options are not consistently named, so you need to use the right option with the right command. In general, the options passin and passout are used. No matter what the option is named, it requires a parameter that specifies how the password or passphrase will be obtained. A variety of sources may be specified, some of them not very secure at all. None of them provides the level of security that someone sitting at the computer and typing in the password or passphrase does, but you need to determine for yourself what you consider to be an acceptable risk.

In Chapter 1, we briefly discussed the need for cryptographic randomness. We’ll expand on this discussion in Chapter 4. For now, we’ll just deal with how to seed the OpenSSL PRNG properly from the command line. Because many of the cryptographic commands depend on random numbers, it is important that the PRNG be seeded properly.

The command-line tool will attempt to seed the PRNG on its own, but it may not always be able to do so. When the PRNG is not properly seeded, the tool will emit a warning message indicating that the random numbers it generates will be predictable. Additionally, you may wish to use a more conservative seeding mechanism than the one used by default.

On Windows systems, a variety of sources will be used to seed the PRNG, including the contents of the screen. None of these sources is particularly entropic, and depending on the version of Windows that you’re using, the entropy sources vary. Unix systems that have a device named /dev/urandom will use that device to obtain entropy for seeding the PRNG. Most modern versions of Unix provide support for this device, which we’ll discuss in detail in Chapter 4. In addition, beginning with Version 0.9.7, OpenSSL will also attempt to seed the PRNG by connecting to an EGD socket to obtain entropy. By default, OpenSSL is built with four well-known names for sockets that it will attempt a connection with.

In addition to the base entropy sources, the command-line tool will also look for a file to obtain seed data from. If the RANDFILE environment variable is set, its value will be used as the name of the file to use for seeding the PRNG. If it is not set, a default filename of .rnd will be used, and the value of the HOME environment variable will be used to specify the location of that file. If the HOME environment variable is not set, as is often the case on non-Unix systems, the current directory will be used to find the file. Once the name of the file has been determined, the contents of that file will be loaded and used to seed the PRNG if it exists.

Many of OpenSSL’s commands require that its PRNG be properly seeded so that the random numbers it generates are unpredictable. In particular, any of the commands that generate key pairs always require unpredictable random numbers in order for them to be effective. When the tool is unable to seed the PRNG on its own, the tool provides an option named rand that can be used to provide additional entropy sources.

The rand option requires a parameter that contains a list of files to be used as entropy sources. The list may be as short as a single file, or as long as the number of filenames you can fit on the command line. Each file in the list is separated by a platform-dependent separator character rather than a space. The separator character is a semi-colon ( ;) on Windows, a comma (,) on OpenVMS, and a colon (:) on all other platforms. On Unix systems, each filename in the list is first checked to see if it is an Entropy Gathering Daemon (EGD) socket. If it is, entropy will be gathered from an EGD server; otherwise, seed data will be read from the contents of the named file.

EGD is an entropy-gathering daemon written in Perl that is intended for use in the absence of /dev/random or /dev/urandom. It is available from http://egd.sourceforge.net/ and runs on any Unix-based system that has Perl installed. It doesn’t work on Windows, but other entropy-gathering solutions are available for Windows. In particular, we recommend EGADS (Entropy Gathering And Distribution System), a C-based infrastructure that supports both Unix and Windows. This is a preferable solution even on Unix machines because it is far more conservative in its entropy collection and estimation. It is even a good solution on systems with a /dev/random. In such cases, it uses /dev/random as a single source of entropy. EGADS is available from http://www.securesw.com/egads/. It can be used anywhere an EGD socket is expected.

If Perl is installed on your system, EGD is easy to set up and run. Perl has become ubiquitous in the Unix world, so it’s unlikely that a modern system does not have it installed. Because EGD uses Perl, it’s very portable, even though it was originally written for Linux systems. On the other hand, EGD works by gathering its entropy from the output of running processes, a number of which produce a questionable amount of unpredictable data. Perhaps its biggest limitation is that it works only on Unix systems.

EGADS can be a bit more difficult to get up and running, but will usually compile straight from the distribution with a minimal amount of effort. On systems that do not have /dev/random, EGADS also gathers its entropy from the output of running processes. These processes are not as widely varied as EGD’s list. EGADS provides an EGD-compatible interface on Unix systems. Because EGADS provides an EGD interface and will use /dev/random to gather entropy, it provides a simplified interface for gathering entropy to clients such as those built with OpenSSL. It also supports Windows NT 4.0 and higher, which have no built-in entropy gathering services. It does not work on Windows 95, 98, or ME. Finally, EGADS also contains a cryptographically secure PRNG.