2
$\begingroup$

Assume two parties have exchanged a secret 128-bit Master Key, MK. When the two parties want to communicate, one of them generates a random 128-bit value, R, which is then sent in plaintext to the other party. Then, a KDF is used to generate a 128-bit Session Key, SK.

SK = KDF(MK, R)

SK is then used to encrypt communication between the parties. Let's say an authenticated encryption algorithm as AES-CCM is used with SK as input.

The question is: is there any difference between choosing a simple AES primitive and the more complex AES-CMAC as KDF?

Improve this question
$\endgroup$
5
  • $\begingroup$ @bkjvbx what do you want me to do with the link? I don't care about the difference in output security between CBC-MAC and CMAC, I care about how that affects the strength of the derivation scheme where the output is kept secret and used to encrypt plaintext. $\endgroup$
    – Bogdan Alexandru
    Commented Aug 10, 2016 at 14:53
  • $\begingroup$ My apologies, I misread. As far as I can tell there would be no difference, since R is just one AES block. They may both be vulnerable to a related key attack, since an active adversary can modify R. Whether or not that is feasible is outside the scope of my knowledge. Is there any reason why you aren't using a hash-based KDF? $\endgroup$
    – bkjvbx
    Commented Aug 10, 2016 at 15:45
  • $\begingroup$ wiki.tools.ietf.org/html/… $\endgroup$
    – bkjvbx
    Commented Aug 10, 2016 at 15:46
  • $\begingroup$ @bkjvbx If comments are not necessary anymore then please delete them. Don't post single link comments unless it is immediately clear why they were posted and what they contain (probably best not post single link answers at all, especially since SE often crops them to a specific size). $\endgroup$
    – Maarten Bodewes ♦
    Commented Aug 25, 2016 at 9:05
  • 1
    $\begingroup$ Neither function is really a KDF, let alone an extract-then-expand KDF. So you don't have the flexibilities that a true KDF supplies, such as differently sized input (Info or OtherInfo), differently sized output (try AES-192 keys for fun), labeling to generate different session keys. We're mainly concerned about security here, so I won't post this as an answer, but beware of the functional properties of your "KDF" as well. $\endgroup$
    – Maarten Bodewes ♦
    Commented Aug 25, 2016 at 9:15

1 Answer 1

Reset to default
1
$\begingroup$

The question is: is there any difference between choosing a simple AES primitive and the more complex AES-CMAC as KDF?

If you use AES as "KDF" in this way, it is equivalent to sending an AES-ECB encrypted key that the recipient decrypts. It's just that you have swapped the direction of encryption and decryption for AES. (AES-ECB is secure with random one-block messages.)

Using CMAC is slower if you take into account the key derivation, but not much different otherwise.

Note that neither version of the protocol has any protection against replay attacks. An attacker can send an R value that has already been used and make the other party reuse a key. Depending on what that session key is actually used for, that can be really bad. (E.g. CTR mode with constant starting nonce.)

A proper protocol would likely let both parties affect the session key. Using e.g. ephemeral Diffie–Hellman with the master key for authentication would be one way to accomplish that while also getting forward secrecy.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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