1
$\begingroup$

Reading the SIV RFC https://tools.ietf.org/html/rfc5297#page-9, I found that the S2V function starts by calculating the MAC of a "zero" block, doubles it and then XORs further data to the result.

Now looking at the BouncyCastle implementation, the exact same thing happens during the initialization of AES-CMAC.

How do I have to understand the S2V specification? Do I have to do all the "zero" stuff and doubling and XORing? Or does this already happen inside the AES-CMAC function? Would that mean, that AES-CMAC(key, plaintext) is equivalent to S2V(key, plaintext)?

$\endgroup$
3
$\begingroup$

Do I have to do all the "zero" stuff and doubling and XORing?

If you are implementing the S2V primitive, using an AES-CMAC function, then yes, you will need to do all that "zero" stuff and doubling and XORing.

Yes, if you peek inside the AES-CMAC function, you will find some logic that looks sort of like this; processing an all zero block, doubling the result, and doing some xor's with it. However, CMAC is doing something a bit different with it (the result of the processed 0 block goes at the end of the chain, not at the beginning), and in any case, the S2V primitive assumes the CMAC logic as a primitive; what CMAC does internally is actually irrelevant to how to implement S2V.

Would that mean, that AES-CMAC(key, plaintext) is equivalent to S2V(key, plaintext)?

No, if you look at the RFC, then the S2V of a vector that consists of a single plaintext (remember, S2V takes a vector of plaintexts) would be either:

  • AES-CMAC( key, plaintext XOR AES( key, 0 )) (for plaintexts >= 128 bits; the xor applies to the end of the plaintext), or
  • AES-CMAC( key, PAD(plainext) XOR double(AES( key, 0 ))) (for plaintexts < 128 bits).
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.