0
$\begingroup$

In evp.h, BytesToKey() generates the key from the passhphrase, IV and the MD5 digest in order to decrypt information used by the public/private keypair generation using AES-256-CBC. I am trying to isolate all the EVP_* functions into a standalone implementation for an embedded system. Does anyone have the actual function or what exactly it does?

KEY DERIVATION ALGORITHM The key and IV is derived by concatenating D_1, D_2, etc until enough data is available for the key and IV. D_i is defined as:

D_i = HASH^count(D_(i-1) || data || salt)
Improve this question
$\endgroup$
5
  • 1
    $\begingroup$ Different versions of openssl enc are incompatible in how they convert password to key, and unless it's a new version and an option is given the hash is not even iterated. See this, which also links to the actual code. In other news, iterated SHA-256 (including PBKDF2 and whatever openssl enc does) is a poor way to use CPU time for password-to-key derivation, because GPUs, FPGAs and ASICs are so much better at it; so the way to go is a memory-hard key stretching function, like Argon2. $\endgroup$
    – fgrieu ♦
    Jul 7 at 5:20
  • $\begingroup$ i just did some further research and realized that in fact MD5 is being used as the default here, even though lots of sources claim that the shift to SHA256 has been made. I was able to call EVP_BytesToKey externally (just a c program), using the IV from my private key and of course my passphrase and the same key was returned using MD5 as the digest. I am just looking for a function that does what BytesToKey does without actually using it because it depends on all these EVP functions and can't be implemented independently $\endgroup$
    – jsmith2001
    Jul 7 at 6:22
  • $\begingroup$ Use of MD5 or SHA-256 depends on version of OpenSSL. Whatever the hash, use with a single iteration to turn a password into key (which is the only setup I know that uses MD5) is extremely insecure (essentially there's no key stretching). It was insecure when defined, and became exponentially more insecure with the advances and spread of CPUs. I see no reasonable use case in a new application. Locating the code should be easy once you have settled on a version, which you did not state. $\endgroup$
    – fgrieu ♦
    Jul 7 at 6:55
  • 1
    $\begingroup$ @fgrieu-onstrike+ the default hash for enc changed in 1.1.0 (up), but BytesToKey remains compatible if you specify the hash (and don't use pbkdf2 option); see my crypto.stackexchange.com/questions/3298/#35614 . But it sounds like this OP might want the encryption OpenSSL uses on 'traditional' (i.e. not PKCS8) privatekey files, which also uses BytesToKey but always with MD5 (no choice) and 1 iteration, and derives only the key while enc does both key and IV, and never uses PBKDF2. $\endgroup$
    – dave_thompson_085
    Jul 7 at 7:01
  • $\begingroup$ OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022) $\endgroup$
    – jsmith2001
    Jul 8 at 18:22

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Browse other questions tagged or ask your own question.