Since this is still open and the issue keeps coming up:
TLDR: There are lots of things in OpenSSL that implement standards including AES, but the key derivation part of
enc is partly nonstandard
First, OpenSSL has several commandline operations it calls commands (although they usually aren't separate programs, as typical commands are on Unix), and a whole range of library calls, that do encryption and decryption with numerous symmetric algorithms of which AES is only one as well as several asymmetric algorithms. Major ones are PKCS#7/CMS and semantically equivalent S/MIME; PKCS#8/rfc5208 and PKCS#12/rfc7292; and the SSL/TLS protocols for which it is named.
The file format with
Salted__ is used by one specific OpenSSL command
enc. Although if the commandline program is given a cipher name instead of a command it silently translates it to
enc -- for example
openssl aes-128-cbc ... is the same as
openssl enc -aes-128-cbc ... -- so people often perceive and describe this as 'OpenSSL AES-128-CBC encryption' as if it were the only AES-128-CBC encryption OpenSSL does.
enc can encrypt and decrypt files (including anything the OS can provide as standard input and output, such as a pipe) with a wide range of options in (mostly) two dimensions:
the symmetric cipher algorithm and mode, and padding. OpenSSL library provides and
enc can use several algorithms, which may vary depending on build but currently default to Blowfish CAST DES DES-EDE(3) (usually called TripleDES TDES or TDEA) IDEA RC2 RC4 Camellia SEED and AES; I haven't bothered linking all the standards. Some algorithms, especially AES, have options for key size. All except RC4 are block ciphers and must be used with a mode such as CBC ECB or CTR; although algorithms and modes are actually defined by separate standards,
enc (and the
EVP API) combines them in a single name.
In addition some modes (CBC and ECB) require data be a multiple of the cipher's block size; since in general real data doesn't do this, it is necessary to add padding when encrypting and remove it when decrypting. By default OpenSSL uses the padding scheme defined by PKCS#7 which extends a scheme defined in PKCS#5, and therefore is usually still called PKCS#5 or just PKCS5 padding. If you specify
-nopad this is not done, and for a block mode encrypting (or decrypting) wrong-size data fails.
all symmetric ciphers require a key, and some modes require an Initialization Vector (IV).
enc can use a 'raw' key and if applicable IV specified on the commandline, with
-K (uppercase!) and
-iv and in hexadecimal. However its default and usual mode is to do Password Based Key Derivation (combined with encryption to give Password-Based Encryption, PBE), and this in turn has several options.
The password can be entered several ways, using legacy option
-k (lowercase) or
-kfile or newer option
-pass or prompted for and typed with no terminal echo (if possible).
The newer, preferred and default option is salted key derivation, which strengthens the derivation (but see below) by using 8-byte random salt. It is also possible to specify a specific salt with
-S in hex, or disable salting with
-nosalt. If salt is used, random or not, a very simple header is added to the ciphertext consisting of the ASCII characters
Salted__ and the 8 bytes of salt. (Standardized PBEs like PKCS#12 also convey the salt, but use much more extensive and flexible formats.)
The key derivation process is based on PBKDF1 from PKCS#5/rfc2898 but modified, and is implemented by the API function
EVP_BytesToKey whose man page should be available in any Unix system with OpenSSL installed and on the website. A bit confusingly, and inconsistent with more recent best practice, this 'key derivation' actually derives both the key and IV if applicable. To lay out the relationship exactly:
PBKDF1 uses a choice of hash from MD2 MD5 SHA1, and an iteration count, and salt. It initially forms
password || salt and hashes it, then hashes the first hash, then hashes the second hash, iterating to a total of count times. PBES1 does use PBKDF1 to produce both key and IV -- but only for RC2 and (single) DES, neither of which is acceptable today.
EVP_BytesToKey uses any hash supported by
EVP, which may depend on build options but currently defaults to MD4 MD5 MDC2 RIPEMD RIPEMD160 SHA1 and the original SHA2 family (but not the later '512 slash' additions), plus iteration count and optional salt. It does one block like PBKDF1 as
H^count (password||salt) with the salt omitted if not used, but if the required 'key material' is more than one block, it then does additional blocks as
H^count (prevblock||password||salt) ditto.
EVP_BytesToKey with salt by default (but see options above), hash MD5 by default (but you can specify otherwise with the previously undocumented option
-md) and iteration count ONE. Thus the key and IV if applicable used by
enc normally is
key[||IV] = b0=md5(t=pw[||salt]) || b1=md5(b0||t) || b2=md5(b1||t) ...
This is not a good PBKDF. Because MD5 is fast and 'iterated' only once, an attacker can quickly try large numbers of possible passwords to find yours, unless your password contains enough entropy without any significant 'strengthening' -- and most people don't choose, and even if given can't remember, such strong passwords.
But we are stuck with it for backward compatibility.
Thus for examples:
openssl rc4-128 [-e|-d] -k sekrit -nosalt
# uses RC4 with 128-bit key derived using no salt, MD5, and count 1 from 'sekrit'
# RC4 is a stream cipher and uses no IV
openssl aes-256-cbc [-e|-d] -k sekrit -md sha1
# uses AES in CBC mode with 256-bit key and 128-bit IV
# (both) derived using random salt, SHA1 and count 1 from 'sekrit'
# and adds the Salted__ header with the salt to the ciphertext
And finally, if you specify
-base64 or the abbreviation
-a, the ciphertext (including header if any) is encoded to base64 on encryption, and decoded from base64 on decryption. This is independent of the other options, and in fact you can use
openssl enc -base64 [-e|-d] to only base64 encode or decode without doing any encryption or decryption at all. Base64 is used, with slight variations, in many standards, but OpenSSL follows the original PEM in 184.108.40.206 (no internal hyperlink because 1993 was before WWW became popular).