In OpenSSL EVP_BytesToKey() can be used for key derivation from a password, hash, and a number of cycles. That all makes perfect sense. The function also can take in a cipher type and salt, and output an IV at the same time. Here’s the signature from the Man page:
int EVP_BytesToKey(const EVP_CIPHER *type, const EVP_MD *md, const unsigned char *salt, const unsigned char *data, int datal, int count, unsigned char *key, unsigned char *iv);
Under what assumed use case is this secure, or more secure?
As far as I know, in the vast majority of cases an IV or nonce should be unique for each message, but doesn’t need to be secret. It looks like an IV is being encrypted or just stretched here. If you have the ability to generate an appropriate salt value why not just generate an IV and include that in the header of your message?
Is the assumption that you’re working in an environment without access to a high quality PRNG (maybe because you’re operating cross platform with just the standard libraries and OpenSSL) and need to stretch your RNG as well as your password?
Or, in the case of a null salt, is it just assumed that most messages will use unique passwords so no effort to have unique IVs needs to be taken? In this use case the output file would probably be raw cyphertext.