DUnderstanding the Pitfalls of SSLv2 - Implementing SSL/TLS Using Cryptography and PKI - page 604

Finally, generate the initialization vectors:
parameters->read_iv = malloc(
parameters->proposed_cipher_spec->IV_size );
parameters->write_iv = malloc(
parameters->proposed_cipher_spec->IV_size );
for ( i = 0; i < parameters->proposed_cipher_spec->IV_size; i++ )
{
// XXX these should be random
parameters->read_iv[ i ] = i;
parameters->write_iv[ i ] = i;
}
Notice that these values are not related to the master key — they're transmitted
directly (in cleartext) to the server. This is generally not a problem because an
attacker still needs to have access to the key in order to make use of the values.
In fact, SSLv3 and TLS 1.0 computed the IVs from the master secret rather than
transmitting them, which was later discovered to be a minor security fl aw and
TLS 1.1+ went back to transmitting them in cleartext just as SSLv2 did. (Although
the fl aw was related to carrying CBC state from one packet to the next, which
SSLv2 also does.)
RC4 does not make use of an initialization vector, but it does need to keep
track of its state from one call to the next. Insert a special RC4-only clause in here
to support this case. If you have other stream ciphers, you should do something
similar for them:
memcpy( parameters->write_key, key_material +
parameters->proposed_cipher_spec->key_size,
parameters->proposed_cipher_spec->key_size );
// Compute IV's (or, for stream cipher, initialize state vector)
if ( parameters->proposed_cipher_spec->cipher_spec_code ==
SSL_CK_RC4_128_WITH_MD5 )
{
rc4_state *read_state = malloc( sizeof( rc4_state ) );
rc4_state *write_state = malloc( sizeof( rc4_state ) );
read_state->i = read_state->j = write_state->i = write_state->j = 0;
parameters->read_iv = NULL;
parameters->write_iv = NULL;
parameters->read_state = read_state;
parameters->write_state = write_state;
memset( read_state->S, '\0', RC4_STATE_ARRAY_LEN );
memset( write_state->S, '\0', RC4_STATE_ARRAY_LEN );
}
else
{
parameters->read_state = NULL;