It sounds like OpenSSL is finally, after at least 6 years, acknowledging that the
enc command has some rather serious flaws (their own man page calls them "bugs"). Maybe they're being fixed now, but if your data is at all important, why not use a (relatively) much more secure tool like GnuPG instead? You don't necessarily need to use public key encryption either, gpg does conventional (password/keyfile only) encryption as well.
Here's an excerpt from my other answer highlighting the basics:
OpenSSL should be able to do all the same things that gpg does, (OpenSSL has been around since 1998, but if version numbers mean anything it reached version 1 in 2010) but it's very easy to make a mistake that could drastically lower the security. And from this post on security.stackexchange.com (from Jan 2013) and another by a 287K reputation user, the
openssl enc command might leave something to be desired:
The encryption format used by OpenSSL is non-standard: it is "what OpenSSL does", and if all versions of OpenSSL tend to agree with each other, there is still no reference document which describes this format except OpenSSL source code. The header format is rather simple:
magic value (8 bytes): the bytes 53 61 6c 74 65 64 5f 5f
salt value (8 bytes)
Hence a fixed 16-byte header, beginning with the ASCII encoding of the string "Salted__", followed by the salt itself. That's all ! No indication of the encryption algorithm; you are supposed to keep track of that yourself.
The process by which the password and salt are turned into the key and IV is not documented, but a look at the source code shows that it calls the OpenSSL-specific EVP_BytesToKey() function, which uses a custom key derivation function with some repeated hashing. This is a non-standard and not-well vetted construct (!) which relies on the MD5 hash function of dubious reputation (!!); that function can be changed on the command-line with the undocumented
-md flag (!!!); the "iteration count" is set by the
enc command to 1 and cannot be changed (!!!!). This means that the first 16 bytes of the key will be equal to MD5(password||salt), and that's it.
This is quite weak ! Anybody who knows how to write code on a PC can try to crack such a scheme and will be able to "try" several dozens of millions of potential passwords per second (hundreds of millions will be achievable with a GPU). If you use "openssl enc", make sure your password has very high entropy ! (i.e. higher than usually recommended; aim for 80 bits, at least). Or, preferably, don't use it at all; instead, go for something more robust (GnuPG, when doing symmetric encryption for a password, uses a stronger KDF with many iterations of the underlying hash function).
man enc even had this under "BUGS":
There should be an option to allow an iteration count to be included.
One of the comments to the first post even mentions these problems have been around for almost 10 years...
This iteration count problem is a real hassle. So much so almost 10 years ago I made a "encrypt" perl script that does essentially the same thing as "openssl enc" but uses Iterative PBKDF2 hashing. ict.griffith.edu.au/anthony/software#encrypt It will decrypt salted "openssl enc" files but re-encrypts using PBKDF2 instead. I would have though OpenSSL file encryption would have improved by now! – anthony Feb 7 at 5:05
Here is an example for symmetric encryption with gpg.
gpg --symmetric --cipher-algo AES256 --output file.gpg file.txt
gpg --decrypt --output file.txt file.gpg