HMAC密钥派生，级联与多个HMAC传递

Question

我正在尝试构建一个泛型函数，用一个全局密钥加密HMAC值，但它可以是“作用域”，也可以是由应用程序/使用来重命名的。例如，会话令牌签名的HMAC不应与用于密码重置令牌签名的HMAC相同。

例如，查看Django，他们只需要创建一个秘密作为new_secret = sha256(salt + main_secret)，基本上，他们通过连接和散列来存储密钥，并将结果用于HMAC密钥。对我来说，这有一个问题:如果HMAC- has 256支持64字节密钥，那么哈希密钥的事实将有效密钥大小减少到32字节(由于sha256的输出)。

另一个实现是AWS的签名v4方法。他们基本上是通过链接HMAC调用来生成新的密钥，例如new_secret = HMAC(main_key, salt)。在我看来，这样做的好处是，只要使用哈希算法输出64个字节，就不会从秘密中“丢失字节”。

在我的用例中，我想要使用各种参数来“加盐”键。一个是静态值(例如，应用程序/功能标识符)，另一个值可以是额外的秘密密钥(例如，用户提供的密钥)。

这样的事会引起什么问题吗？

def get_hmac_derived_key(secret, salts, digest=sha512):
    # We will use a similar key derivation and signature implementation
    # as AWS signature v4.

    def derive_key(key, msg):
        return hmac.new(key, msg, digest).digest()

    if not salts:
        raise ValueError("No salts provided.")

    derived = force_bytes(secret)

    for s in salts:
        derived = derive_key(derived, force_bytes(s))

    return derived

# Example usage
derived_secret = get_hmac_derived_key(BASE_SECRET, ['my.app.feature1', 'extra-salt-1', USER_SECRET])

signature = hmac.new(derived_secret, msg="my message", digestmod=sha256).digest()

或者多个HMAC通行证没有好处，而应该是公正的：

signature = hmac.new(sha512('my.app.feature1' + 'extra-salt-1' + BASE_SECRET + USER_SECRET), msg="my message", digestmod=sha256).digest()

注意:使用sha512进行密钥派生，因此输出仍然是64个字节( hmac-sha256的块大小，否则python的HMAC代码将仅为sha256(..)我们的钥匙)

最后，另一种选择是只在信息中包含盐类/标识符，但这可能会给出重叠的信息，并可能破坏整个信息。例如，signature = hmac.new(BASE_SECRET, msg='my.app.feature1' + ':' + 'extra-salt-1' + ':' + USER_SECRET + ':' + "my message", digestmod=sha256).digest()

Answer 1

我在这里推荐的方法是香港发展基金。这是一个基于HMAC的密钥派生函数，非常适合以这种方式导出密钥，实际上是TLS1.3使用的算法。

该过程由两个步骤组成:提取和展开。提取步骤可以采取盐，而展开步骤也可以采取盐在其信息参数，如果你需要支持额外的盐类。然后，您可以派生出所需的任何键。请注意，如果在info参数中使用salt，请确保标签和salt不会混淆(例如，插入一个从未出现在salt之前的标签中的分隔符)以避免攻击。

如果您使用HMAC-SHA-256，那么提取步骤确实会将安全性降低到256位。然而，我们已经认为128比特的安全性对于未来的无限发展是足够的，而256位的安全性被认为远远超出了这个星球使用理论上最小能量所能支持的计算极限。如果您真的非常关心这一点，您可以使用HMAC-SHA-512来避免降低64字节密钥以外的安全性。

如果您有HMAC，HKDF也很容易实现:您所需要做的就是执行一两次特殊格式的HMAC调用。

使用HMAC链接派生密钥的方法可能是安全的。我在其他地方见过它，我不知道它有什么问题。然而，TLS 1.3使用HKDF进行重复推导，这是我推荐的标准方法。