Authenticating Communications Using Digital Signatures - Implementing SSL/TLS Using Cryptography and PKI - page 168

}
else
{
md5_block_operate( input, hash );

input += MD5_BLOCK_SIZE;
len -= MD5_BLOCK_SIZE;
}
}

// There's always at least one padded block at the end, which includes
// the length of the message
memset( padded_block, 0, sizeof( padded_block ) );
if ( len >= 0 )
{
memcpy( padded_block, input, len );
padded_block[ len ] = 0x80;
}

// Only append the length for the very last block
// Technically, this allows for 64 bits of length, but since we can only
// process 32 bits worth, we leave the upper four bytes empty
// This is sort of a bizarre concept of “little endian”...
padded_block[ MD5_BLOCK_SIZE - 5 ] = ( length_in_bits & 0xFF000000 ) >> 24;
padded_block[ MD5_BLOCK_SIZE - 6 ] = ( length_in_bits & 0x00FF0000 ) >> 16;
padded_block[ MD5_BLOCK_SIZE - 7 ] = ( length_in_bits & 0x0000FF00 ) >> 8;
padded_block[ MD5_BLOCK_SIZE - 8 ] = ( length_in_bits & 0x000000FF );

md5_block_operate( padded_block, hash );

return 0;
}

NOTE Notice that this code requires that the entire input to be hashed be
available when this function is called. As it turns out, you can't assume that
this is always be the case. I address this shortcoming later.

Now, follow these steps:

1. Initialize the hash response to the standard starting value defi ned earlier.

2. Iterate through 512-bit blocks, calling md5_block_operate until you come
to the last, or next-to-last block depending on whether the last block aligns
on less than 448 bits or not.

3. If the last block is between 448 and 512 bits (56 and 64 bytes), pad by add-
ing a “1” bit, which is always hex 0x80 because this implementation never
accepts non-byte-aligned input, and fi ll the rest of the buffer with 0's.

4. The length is appended to the next block. Set len -1 as a reminder for

the next section not to append another “1” bit.