Cryptography Reference
In-Depth Information
when such a message is received has never been defi ned, so you don't have to
worry about it. However, technically you ought to ensure that the size of the
outgoing packet is never greater than 2^14 = 16,384 bytes.
The second buffer, encrypted , is the buffer that's passed into the bulk encryp-
tion routine. You may wonder why another buffer is needed for this purpose.
After all, the input parameter data is the plaintext to be encrypted. Well,
SSLv2 requires that you prepend this data with a MAC and then encrypt the
whole thing.
So, the next thing to do is to generate the MAC in the fi rst mac - length bytes
of the encrypt buffer.
mac_buf = malloc( data_len + padding );
memset( mac_buf, '\0', data_len + padding );
memcpy( mac_buf, data, data_len );
add_mac( encrypt_buf, mac_buf, data_len + padding, parameters );
free( mac_buf );
As you can see, another buffer is used to MAC the data to be sent; this includes
the plaintext data, plus the padding (the padding must be MAC'ed). Invoke
add_mac in Listing C-25 to actually generate the MAC.
Listing C-25: “ssl.c” add_mac
static void add_mac( unsigned char *target,
const unsigned char *src,
int src_len,
SSLParameters *parameters )
{
digest_ctx ctx;
int sequence_number;
parameters->active_cipher_spec->new_digest( &ctx );
update_digest( &ctx, parameters->write_key,
parameters->active_cipher_spec->key_size );
update_digest( &ctx, src, src_len );
sequence_number = htonl( parameters->write_sequence_number );
update_digest( &ctx, ( unsigned char * ) &sequence_number,
sizeof( int ) );
finalize_digest( &ctx );
memcpy( target, ctx.hash,
parameters->active_cipher_spec->hash_size );
}
Notice that SSLv2 does not use the HMAC function. HMAC wasn't actually
specifi ed until 1997. Instead, SSLv2 uses a slightly weaker form that concatenates
the write secret, the data, and a sequence number, and then securely hashes
this combination of things.
 
Search WWH ::




Custom Search