1. 我在解释中的逻辑有道理吗？

HMAC是从密码散列函数构造伪随机函数(PRF)的一种技术.它通过使用密钥来实现这一点，这个键被松散地称为键-散列。

在扩展和提取步骤中，HKDF使用HMAC作为PRF和可以很容易地用于派生多个键。。基于PRF的扩展步长的安全性和任何安全的随机抽取器都可以用于步长的提取。

前缀- PRF函数F_k\colon m \mapsto H(k \mathbin\| m)被推测为PRF，这是SHA-3的设计目标.NIST将KMAC设计为具有一定域分离的MAC。

KMAC是一个PRF (猜想)，所以可以用KMAC代替HMAC。KMAC实现PRF的速度更快，因为它不需要像HMAC那样使用双哈希(记住前缀构造上的长度扩展攻击)。

另外，椭圆曲线点的编码也是不一致的。要从ECDH的输出中派生密码密钥，始终建议使用加密散列函数进行散列。

1. S_{AB}作为加密密钥还是用于MAC的密钥是安全的？

好的，正如在评论中所说的，在散列/PRF中添加更多的上下文，包括通过连接的上下文；公钥、时间戳、用途、应用程序等等。

1. 有什么简单的改进可以使这个算法更安全吗？

上下文建议在1和使用HKDF与KMAC。现在，香港发展基金在TLS 1.3中。这是众所周知的。另外，还可以使用ECDH+KDF派生初始密钥，然后仅通过更改info参数就可以使用HKDF派生多个密钥。只需在初始键上一次又一次地调用展开。

这也可以用KMAC的S参数来完成。我看不出那里有危险。

TL;DR 是，您可以使用KMAC作为KDF，最好使用KDF的NIST标准中定义的KMAC。

这是在NIST SP 800-108r1,2022年8月，使用伪随机函数的密钥推导，第4.4节中指定的。

让我们引用有关的部分：

在本节中，KMAC#的KDF规范(K、X、L、S)采用以下参数：

1. K_{IN} -密钥派生键；
2. X -上下文，包含与派生的键控材料相关的信息的位字符串；
3. L−是一个整数，用于指定导出的键控材料的所需输出长度(以比特为单位)；
4. 标签( S KDF4X)是一个可选的定制位字符串；例如，标签可以是8位−中的字符“KDF”或“KDF4X”的编码。

K_{OUT} = KMAC\#(K_{IN}, X, L, S)。

在这里，KMAC#表示KMAC128或KMAC256的使用。为了清晰起见，我删除了参数的重新映射(K到K_{IN}，S到Label等等)。

约翰·凯尔西在NIST网站上的介绍展示了如何和为什么可以使用KMAC作为KDF。

比特依赖于输入键控材料的所有比特的想法来自于作为PRF提供的功能。并不是所有的MAC都被认为是PRF的，但是KMAC当然是。

KMAC被显式定义为提供域分离和SHA3，域分离使用配置字符串以及可配置的输出大小。因此，它的位置非常适合用作KDF。

评论；

• 如果将KMAC用作KDF，我强烈建议提供配置字符串S，因为这也意味着在相同大小的输入/输出上计算MAC不太可能产生相同的输出。NIST建议将字符串"KDF"作为域分离的前缀。当然，无论如何都应该避免为不同的目的重用密钥。
• 上下文X也是可选当前的位置。盐还没有被定义，但是盐和“随机的现在”是一样的。添加一个盐很可能会增加功能的安全性，请参阅HKDF规范以获得更多信息。
• 我自己使用标签L设置为“KCV”来创建一个键检查值，在可能的情况下也使用随机的nonce。

KMAC的一个更棘手的属性是，如果输出大小以不同的方式指定，则函数的输出是无关的。一方面，这意味着它是“更难射击自己的脚”和泄漏的关键材料。这也意味着您不能使用KMAC来生成流。由于这个原因，最好对每个秘密的或随机的成分分别调用函数，例如key和IV。

幸运的是，KMAC的效率相对较高，有单独的呼叫通常是可以的。它还能更好地应用于例如硬件设备；让KDF同时吐出一个键和一个IV可能很难实现，因为IV与关键对象没有直接关系。

为了完整起见，我将包括KMAC的定义，这样您就可以看到参数是如何在cSHAKE哈希函数中使用的。如果你不介意的话，我不会深入cSHAKE的。

KMAC128和KMAC256本身已经在NIST SP 800-185，第4.3节中定义了。KMAC128被定义为：

1. newX =字节码(encode_string(K)，168) \x\x\{e76f} right_encode(L)。
2. 返回cSHAKE128(newX，L，“KMAC”，S)。

对于KMAC256，将168替换为136，将cSHAKE128替换为cSHAKE256。