[openssl-users] SHA256() to EVP_* ?

[Dave Thompson]

> From: openssl-users On Behalf Of jonetsu
> Sent: Tuesday, April 28, 2015 13:53

> What would be the equivalent of the SHA256() function in the EVP
> class of methods ?  EVP_sha256() could be it, although from the
> short description in manual page it does not seemingly fit in,
> returning a EVP_MD which is, if not mistaken, a env_md_st
> structure.
> 
The LOWLEVEL modules use separate routines. There are routines 
for SHA1, and *separate* routines for SHA256, and separate routines 
for SHA384, and separate routines for MD5, and separate routines for 
RIPEMD160. There are routines for AES, and separate routines for 
RC4, and separate routines for Blowfish, and routines for DES and 
"tripleDES" aka DESede that overlap *some* because of the very 
close relationship but separate from all other symmetric ciphers. 
There are routines for RSA, and separate routines for DSA, and 
separate routines for DH, and separate routines for ECDSA, 
and separate routines for ECDH. 

EVP DOES NOT. EVP has *one* set of digest routines used for ALL 
digest algorithms, but with a data object specifying *which* digest.
EVP has *one* set of Cipher routines used for all symmetric ciphers,
with a data object specifying which. EVP has due to history *two* 
sets of asymmetric signature routines, which apply to three (and 
possibly more) asymmetric algorithms specified by data objects.

Thus the EVP equivalent to the SHA256*() lowlevel calls is 
to call the EVP_Digest* routines with a data object specifying 
SHA256, which is exactly what the value of EVP_sha256() is.

The man page named for EVP_DigestInit which also covers 
EVP_DigestInit_ex, EVP_DigestUpdate, EVP_DigestFinal,
EVP_DigestFinal_ex, and some related routines (although 
the link for EVP_DigestFinal original seems to be missing)
tells you how to do digests with EVP in general. Apparently 
it wasn't updated to list SHA2 digests, but that variation 
should be obvious from documented pattern.
 
> The code I'm adapting to EVP has a first pass of shortening the
> key if too long:
> 
>     /* Change key if longer than 64 bytes */
>     if (klen > HMAC_INT_LEN) {
> 			SHA256(key, klen, nkey);
> 			key = nkey;
> 			klen = SHA256_DIGEST_LENGTH;
>     }
> 
> Before proceeding with the usual SHA256_Init(),
> SHA256_Update() (twice), and SHA256_Final.  All of which I have
> tested with the corresponding EVP_* methods.  For the use of
> SHA256() above, though, I'm puzzled regarding its EVP_*
> counterpart.
> 
If you are implementing HMAC, perhaps for PBKDF2 (which does 
that prehash-if-too-long), I hope you mean the code does 
one hash of ipad+data, which can consist of Init, 2 Updates, 
and Finial (although there are other ways) and then a SECOND 
ENTIRE HASH of opad+innerhash, similarly. If that's not what 
you're doing, you're not doing standard HMAC, so it definitely 
won't be interoperable and may well not be secure, because 
HMAC was defined the way it is precisely because it was found 
the naïve way merely hashing key+data is not reliably secure.

Although if what you want is PBKDF2-HMAC, there is already 
two OpenSSL routines for that (again due to history).