Cryptography Reference
In-Depth Information
Notice that there are quite a few more
k
values for SHA-256 than for SHA-1,
and that
shows up only in the computation of
W
and
in the main loop. You
also have to have an
initial hash
in Listing 4-18.
Listing 4-18:
“sha.c” SHA-256 initial hash
static const unsigned int sha256_initial_hash[] =
{
0x67e6096a,
0x85ae67bb,
0x72f36e3c,
0x3af54fa5,
0x7f520e51,
0x8c68059b,
0xabd9831f,
0x19cde05b
};
These are presented here backward (that is, in little-endian format) with
respect to the specifi cation. If you want to invoke this, you need to call the same
digest_hash
function developed earlier:
unsigned int hash[ 8 ];
memcpy( hash, sha256_initial_hash, 8 * sizeof( unsigned int ) );
digest_hash( argv[ 2 ], strlen( argv[ 2 ] ), hash, 8, sha256_block_operate,
sha1_finalize );
Notice that the fi nalize pointer points to
sha1_finalize
— fi nalization is
exactly the same for SHA-256 as it is for SHA-1, so there's no reason to defi ne
a new function here.
Preventing Replay Attacks with the HMAC Keyed-Hash
Algorithm
Related to message digests (and particularly relevant to SSL) are HMACs, speci-
fi ed in RFC 2104. To understand the motivation for HMAC, consider the secure
hash functions (MD5 and SHA) examined in the previous three sections. Secure
hashes are reliable, one-way functions. You give them the input, they give you
the output, and nobody — not even you — can work backward from the output
to uncover the input. Right?
Well, not exactly — or at least, not always. Imagine that a company maintains
a database of purchase orders, and to verify that the customer is in posses-
sion of the credit card number used to place an order, a secure hash of the
credit card number is stored for each order. The customer is happy, because
her credit card number is not being stored in a database for some hacker to
steal; and the company is happy, because it can ask a customer for her credit
card number and then retrieve all orders that were made using that card for
Search WWH ::
Custom Search