Hi all,
What is the issue? The derivation of MK uses "0x00" as a key for the
KDF.
Here is the key derivation step:
MK = GKDF-16 (zero, PL || PSK || CSuite_Sel || inputString)
^^^^^
Here is the problem.
Here is what Charles recognized during the discussion:
"
I just looked though the definition of CMAC, the MAC used in one of our
two ciphersuites, and the zero key looks like it might cause some
problems. Unlike the HMAC ciphersuites, it doesn't simply concatenate
the key with the data input. The first step is to compute:
k0=E_k(0x00)
k1=k0*x mod p(x)
k2=k1*x mod p(x)
These values would always be fixed. During the CBC operation, they are
XOR'd with the final message block. k1 is XOR'd if the final message
block's length matches the encryption block length. k2 is used
otherwise on a message padded with 1000...0000b.
I think what using an all-zero key does is reduce the security of CMAC
to the security of CBC-MAC with an all-zeros IV. While the
ramifications of this are debatable for our applications, it's still
probably not a great idea.
Currently we can't use the PSK as the input to the first KDF because its
length may not match the selected ciphersuite's block length. We wanted
to try to do was have a ciphersuite that could be implemented using only
AES.
"
Do you agree that the problem is real?
If yes, then we believe that there are the following solution steps:
1) We would need some way to normalize the length of the PSK for the
selected ciphersuite. We could define an additional cryptographic
primitive in every ciphersuite that does this derivation, such as
SHA256-128 for the AES ciphersuite and SHA256 for the HMAC ciphersuite.
2) We could switch to a different KDF, for example to the one used for
IKEv2.
Can you come up with other solution approaches?
Which solution approach should we pick?
Ciao
Hannes
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
