Problem - Kevin Tafuro

divide up the data stream between those MACs. For example, you might run two
MACs in parallel and alternate sending 64 bytes to each MAC.
The problem with doing this is that your two MAC’s authentication values need to
be tied together; otherwise, someone could rearrange the two halves of your stream.
For example, if you were to MAC this message:
ABCDEFGHIJKL
where MAC 1 processed the first six characters, yielding tag A, and MAC 2 processed
the final six, yielding tag B, an attacker could rearrange the message to be:
GHIJKLABCDEF
and report the tags in the reverse order. Authentication would not detect the change.
To solve this problem, once all the MACs are reported, MAC all the resulting tags to
create a composite MAC. Alternatively, you could take the last MAC context and
add in the MAC values for the other contexts before generating the tag, as illustrated
in Figure 6-8.
Original message M 1
MAC
MAC
If your MAC accepts a nonce, you can use the same key for each context, as long as
you never reuse a {key, nonce} pair.
Here’s a simple sequential example that runs two OMAC1 contexts, alternating
every 512 bytes, that produces a single resulting tag of 16 bytes. It uses the OMAC1
implementation from Recipe 6.11.
#include
M 1
Figure 6-8. Properly interleaving MACs
#define INTERLEAVE_SIZE 512
M 2
M 2
unsigned char *spc_double_mac(unsigned char *text, size_t len,
unsigned char key[16]) {
SPC_OMAC_CTX ctx1, ctx2;
unsigned char *out = (unsigned char *)malloc(16);
unsigned char tmp[16];
if (!out) abort(); /* Consider throwing an exception instead. */
spc_omac1_init(&ctx1, key, 16);
spc_omac1_init(&ctx2, key, 16);
while (len > 2 * INTERLEAVE_SIZE) {
M 3
M 3
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.
M 4
M 4
M 5
M 5
T 1
T 1
Output
Parallelizing MACs | 305