TLS 1.3 及其對 HKDF-Extract 的使用

HKDF-Extract 在RFC 5869中定義為

 HKDF-Extract(salt, IKM) -> PRK

  Options:
     Hash     a hash function; HashLen denotes the length of the
              hash function output in octets

  Inputs:
     salt     optional salt value (a non-secret random value);
              if not provided, it is set to a string of HashLen zeros.
     IKM      input keying material

在TLS 1.3 密鑰調度中，從 Handshake Secret 派生的 Secret 用作生成 Master Secret 的 salt 輸入，其中 IKM 是一串 0。然而，這似乎與 HKDF-Extract 對鹽的定義不一致；這是非秘密的。TLS 1.3 是否錯誤地使用了 HKDF-Extract？

TLS 1.3 是否錯誤地使用了 HKDF-Extract？

不，不幸的是，(a non-secret random value)摘要有些誤導。

HKDF RFC允許並且基本上鼓勵使用一種秘密鹽（如果有的話）：

值得注意的是，雖然不是典型情況，但某些應用程序甚至可能有一個秘密的鹽值可供使用；在這種情況下，HKDF 提供了更強大的安全保障。此類應用的一個範例是 IKEv1 在其“公鑰加密模式”中，其中提取器的“鹽”是從秘密的隨機數中計算出來的；類似地，IKEv1 的預共享模式使用從預共享密鑰派生的秘密鹽。

這是因為鹽被用作 HMAC 的密鑰，而密鑰是一件好事。

我認為他們將其總結為非機密，因為通常情況如此，也許他們希望人們閱讀整個文件。無論哪種方式，它確實應該說(a secret or non-secret random value)清楚。

正如在另一個答案中已經提到的，HKDF 的隨機性提取方法只是呼叫 HMAC，以 salt 作為鍵，將 Input Keying Material 作為 HMAC 輸入。那是 $ \mathsf{Extract}(salt, ikm) = \mathsf{HMAC}(salt, ikm) $ .

在高層次上， $ ikm $ 是從一個高最小熵（不一定是統一的）源中提取的，我們想從中提取一個統一的密鑰 $ ikm $ .

Krawczyk 在 HKDF 論文中陳述了密鑰派生函式的正式定義：https ://eprint.iacr.org/2010/264.pdf 。在高層次上，這是一個安全遊戲，要求對手區分隨機值和源自秘密的值 $ ikm $ . 攻擊者還得到了 IKM 源和密鑰推導中使用的鹽的描述。因此，安全概念並不要求鹽是秘密的。

*那麼在 TLS 1.3 中發生了什麼？*回顧 $ \mathsf{Extract}(salt, ikm) = \mathsf{HMAC}(salt, ikm) $ . 因此，如果 $ salt $ 不僅是秘密的，而且是至關重要的偽隨機，這是 HMAC 作為偽隨機函式的正常“安全”呼叫。這是一種合法的用法，因為在這一點上，派生的握手秘密被認為是偽隨機的，當使用偽隨機密鑰鍵入時，PRF 會為每個新輸入生成偽隨機輸出。我認為這是對符號的濫用，因為 HMAC 是 HKDF 中的基礎原語。此外，由於用於主密鑰的 IKM 是一個固定的 0 值，因此談論隨機性提取似乎很奇怪。固定值沒有太多

引用自：https://crypto.stackexchange.com/questions/101306