What are KDF parameters in OpenSSL command-line utility for `enc`? I refer to https://www.openssl.org/docs/manmaster/apps/enc.html and see that the only parameter for key derivation which I can set explicitly (not considering the obvious -S for setting salt) is -md which is MD to be used for key derivation algorithm.

Now the question is: what are other implicit parameters for KDF when using OpenSSL in cmd mode? In particular, does it use PBKDF2? And if so - the most important question: what is the default value for number of KDF iterations? I can't find those values.

I am using OpenSSL cmd utility to encrypt plaintexts. The result is decrypted using another crypto library. I need to test password-based encryption in particular.

To make it more clear: I want to save generated salts and passwords, then decrypt ciphertexts with another crypto library which does use PBKDF2 with HMAC_SHAxxx algorithms and gives the opportunity to set number of KDF rounds as well. So I want to have a possibility to derive exactly same keys from passwords and salts as OpenSSL cmd utility does.

Finally, maybe the idea to rely on cmd utility is somewhat bad considering my task. If so, I want to hear your opinion on this, too.

I've got OpenSSL 0.9.8zh 14 Jan 2016 (OS X).
OpenSSL uses EVP_BytesToKey, an algorithm proprietary to OpenSSL, with a salt and an iteration count set to 1. The algorithm is secure; the iteration count of 1 of course is not secure (for passwords with an average strength). Implementations for other languages/runtimes can be found by searching for it by name.

This page (on nabble.com) explains a bit about accessing PBKDF2 from the command line. It also shows that OpenSSL CLI isn't always taken that seriously; OpenSSL is mainly a cryptographic library that can also be used from the command line.

It is possible to find code to include the iteration count in the CLI in the answers to this question on the security site (not reviewed by me). That code is however specific to private keys encrypted using the PKCS#8 standard.

It could well be that PGP is more suited for end-to-end password encryption (I haven't reviewed it for a while). It was certainly more specifically created for it.