Cryptography Reference
In-Depth Information
return length;
}
This is nothing but a wrapper around send_message , which examines the active
protection parameters and applies them to the data buffer before sending it on.
TLS Receive
tls_recv , shown in Listing 6-70, can take advantage of the decrypt support
added to receive_tls_message . However, receive_tls_message expected to
handle the received packet after decrypting it. tls_recv wants the data itself,
so receive_tls_message also needs to be updated as shown in Listing 6-71 to
optionally pass back a chunk of decrypted data.
Listing 6-70: “tls_recv”
int tls_recv( int connection, char *target_buffer, int buffer_size, int options,
TLSParameters *parameters )
{
int bytes_decrypted = 0;
bytes_decrypted = receive_tls_msg( connection, target_buffer, buffer_size,
parameters );
return bytes_decrypted;
}
Listing 6-71: “receive_tls_msg” with optional response buffer
static int receive_tls_msg( int connection,
char *buffer,
int bufsz,
TLSParameters *parameters )
{
if ( message.type == content_handshake )
{
else if ( message.type == content_application_data )
{
memcpy( buffer, decrypted_message, decrypted_length );
}
...
This means that the invocations of receive_tls_msg in tls_connect must
also be updated to pass a null pointer, shown in Listing 6-72.
Listing 6-72: “tls.c” tls_connect with receive_tls_msg calls updated
int tls_connect( int connection,
TLSParameters *parameters )
{
Search WWH ::




Custom Search