Problem - Kevin Tafuro

CryptAcquireContext(&hProvider, 0, MS_DEF_PROV, PROV_RSA_FULL, 0);
CryptCreateHash(hProvider, Algid, 0, 0, &hHash);
CryptHashData(hHash, pbIn, cbIn, 0);
CryptGetHashParam(hHash, HP_HASHSIZE, (BYTE *)cbOut, &cbData, 0);
pbOut = (BYTE *)LocalAlloc(LMEM_FIXED, *cbOut);
CryptGetHashParam(hHash, HP_HASHVAL, pbOut, cbOut, 0);
CryptDestroyHash(hHash);
CryptReleaseContext(hProvider, 0);
return pbOut;
}
See Also
Recipe 6.7
6.7 Using a Cryptographic Hash
Problem
You need to use a cryptographic hash function outside the context of a MAC, and
you want to avoid length-extension attacks, which are quite often possible.
Solution
A good way to thwart length-extension attacks is to run the hash function twice, once
over the message, and once over the output of the first hash. This does not protect
against birthday attacks, which probably aren’t a major problem in most situations. If
you need to protect against those attacks as well, use the advice in Recipe 6.8 on the
first hash operation.
Discussion
Hash functions are not secure by themselves—not for a password system,
not for message authentication, not for anything!
Because all of the commonly used cryptographic hash functions break a message into
blocks that get processed in an iterative fashion, it’s often possible to extend the message
and at the same time extend the associated hash, even if some sort of “secret”
data was processed at the start of a message.
It’s easy to get rid of this kind of problem at the application level. When you need a
cryptographic hash, don’t use SHA1 or something similar directly. Instead, write a
wrapper that hashes the message with your cryptographic hash function, then takes
that output and hashes it as well, returning the result.
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.
Using a Cryptographic Hash | 269