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