> 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).
