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