Cryptography Reference
In-Depth Information
Listing 9-29: “tls.c” send_message with AEAD encryption support
if ( active_suite->bulk_encrypt || active_suite->aead_encrypt )
{
unsigned char *encrypted_buffer = malloc( send_buffer_size +
active_suite->IV_size +
( active_suite->aead_encrypt ? active_suite->hash_size : 0 ) );
int plaintext_len;
// TODO make this random
memset( parameters->IV, '\0', active_suite->IV_size );
// The first 5 bytes (the header) and the IV aren't encrypted
memcpy( encrypted_buffer, send_buffer, 5 );
memcpy( encrypted_buffer + 5, parameters->IV, active_suite->IV_size );
plaintext_len = 5 + active_suite->IV_size;
if ( active_suite->bulk_encrypt )
{
active_suite->bulk_encrypt( send_buffer + 5,
send_buffer_size - 5, encrypted_buffer + plaintext_len,
parameters->IV, parameters->key );
}
else if ( active_suite->aead_encrypt )
{
active_suite->aead_encrypt( send_buffer + 5,
send_buffer_size - 5 - active_suite->hash_size,
mac_header, 13, ( encrypted_buffer + active_suite->IV_size + 5 ),
parameters->IV, parameters->key );
}
free( send_buffer );
send_buffer = encrypted_buffer;
send_buffer_size += active_suite->IV_size;
}
...
As you can see, other than allocating enough space in the target encryption
buffer for the MAC, this isn't that much different than ordinary block cipher
encryption.
Decrypting with AEAD cipher support is about the same. First, declare
a mac_header independent of the MAC buffer and precompute it. However,
remember that the length declared in the MAC header was the length of the
data before padding or the MAC was added. For this reason, it's impossible,
in the block cipher case, to precompute the MAC header before decrypting the
data; you need to know how much padding was added, and you can't do that
without decrypting. All this means is that a bit of code — the MAC header
computation — must be duplicated in tls_decrypt as shown in Listing 9-30
whereas it was reused in send_message .
Search WWH ::




Custom Search