2個鍵的拆分雜湊
這些是步驟：
- 使用 SHA3-512 散列 ECDH 共享密鑰
- 連接奇數字節並使用 SHA3-512 重新散列以獲取 AES-256 密鑰
- 連接偶數字節並使用 SHA3-512 重新散列以獲取 KMAC 密鑰
這個密鑰派生安全嗎？如果沒有，缺點是什麼？
您描述的密鑰派生過程在技術意義上是相當安全的，但不是一個好的選擇——它不是很靈活，它會引起審計人員的注意，而 SHA3-512 並不是一個好的設計。
如果我們將 SHA3-512 建模為統一隨機函式，則安全性 $ H $ : 512 字節中的每一個 $ H $ 在不同的 DH 秘密上是獨立均勻隨機的，因此 256 個奇數位置字節的字元串是均勻隨機的，而 256 個偶數位置字節的字元串是獨立均勻隨機的。偶數位字節和奇數位字節之間的衝突機率可以忽略不計，並且在沒有衝突的情況下，生成的密鑰是獨立的均勻隨機的。
為什麼這是一個糟糕的選擇？
- 它不是很靈活。 當您想派生另一個密鑰時會發生什麼？您已經用完了所有字節（或者，無論如何，它們中的大部分）；為此，您需要找到一種不同的機制，這將是另一個**臨時的事情，其餘的原因仍然適用。這種脆弱性可能會損害安全性：需要擴展協議的繼任者會做出保持安全的決定嗎？
- 它將引起審計人員的注意。 這不是密鑰派生的標準結構。通過採用這一點，您可以強制審計員進行上述段落中的密碼推理，而審計員不願意這樣做，從而使審計員的工作變得更加困難。他們不想考慮 SHA3-512 雜湊的偶數位和奇數位字節。他們寧願花精力簡單地確認您使用的是經過充分研究和充分理解的結構，而無需考慮它，因此他們可以繼續處理更高級別的協議問題，這些問題實際上在評估您的應用程序的安全性。
- SHA3-512 並不是一個好的設計。 SHA3-512 為您無法想像的高安全級別支付額外費用，原因有兩個：
- 碰撞攻擊與您的應用程序無關，但 SHA3-512 為抗碰撞性付出了額外的代價。
- 出於政治原因而非技術原因，SHA3-512 被過度設計以滿足毫無意義的安全目標。除了一般建議：忽略 SHA3-256 和 SHA3-512。對於 128 位安全級別，使用 SHAKE128（具有足夠長的輸出）。僅當您偏執地擔心對沖適度的密碼分析進步時才使用 SHAKE256，例如與 Ed448 一起使用。
那麼你應該怎麼做呢？這裡有幾個選項：
- 將 HKDF 與您最喜歡的雜湊函式一起使用。 SHA-256 是一個非常值得尊敬的選擇。如果您堅持使用 SHA-3，則可以使用 SHA3-256，但 SHAKE128-256 會更快，以實現基本相同的安全性——或者您可以直接使用 SHAKE128 或 KMAC128，如下所示。
HKDF 分為兩個階段，一些 API 將它們結合在一起：
HKDF-Extract採用初始密鑰材料和鹽並將它們散列成主密鑰。
- 初始密鑰材料是高熵但可能不統一的秘密，例如 DH 密鑰協議的結果。
- 鹽是可選的；如果它只是對每個使用者不同，那麼它可以用來減輕多目標攻擊。對於已經達到 128 位安全級別的 DH 密鑰協議，例如 X25519，這不是必需的。但它不疼。
- 主密鑰是一個短的秘密比特串，實際上是均勻隨機的。$$ \begin{equation*} k_{\mathrm{master}} = \operatorname{HKDF-Extract}(\mathit{dhsecret}) \end{equation*} $$
您絕不能重複使用相同的初始密鑰材料。 （實際上，實際上，如果你用不同的鹽重用它，你不會遇到安全問題——但你會讓審計員的工作更難，這會讓你的生活變得更艱難，並損害使用者對你係統的信心。）
HKDF-Expand採用主密鑰和唯一描述目的的資訊參數並從中派生**子密鑰。
- 萬能鑰匙是您從 HKDF-Extract 中得到的。（除此之外：它也可能來自像 Argon2 或 PBKDF2 這樣的密碼雜湊，或者您從其他地方獲得的任何短的統一隨機密鑰，而您只想從中派生多個子密鑰。）
- info參數區分子密鑰用於不同目的：對於每個不同的info，都有一個有效獨立的統一隨機子密鑰；就好像您獨立生成了子密鑰，但您可以通過傳遞相同的資訊從主密鑰中確定性地和可重複地獲取它。
- 子密鑰是您然後用作 AES-256 密鑰或其他什麼的。$$ \begin{align*} k_{\mathrm{AES}} &= \operatorname{HKDF-Expand}{k{\mathrm{master}}}(\text{‘AES encryption key’}), \ k_{\mathrm{KMAC}} &= \operatorname{HKDF-Expand}{k{\mathrm{master}}}(\text{‘KMAC authentication key’}). \end{align*} $$
您絕不能將相同的 info 參數用於兩種不同的目的。 審核員希望很容易確認您派生子密鑰的每個目的都有一個不同的資訊參數，因此您應該清楚地記錄每個資訊參數的用途，如果您曾經以程式方式格式化資訊參數，請確保您對放入其中的任何數據使用唯一編碼，以確保它們是唯一的。 2. 直接使用 KMAC128 或 SHAKE128。 對於 KMAC128，您可以安全地將 DH 機密作為 KMAC128 密鑰輸入，並將 salt 和 info 參數唯一編碼為 KMAC128 消息。同樣，您也可以將 DH 秘密、鹽和資訊參數唯一地編碼為 SHAKE128 消息： $ \operatorname{SHAKE128}(\text{32-byte DH secret} \mathbin| \text{32-byte salt} \mathbin| \text{‘AES key’}) $ .
這對您的應用程序可能更簡單，並且不會損害安全性。只要它在概念上的結構與 HKDF 相同——從不重用 DH 機密，除非具有不同的資訊參數——審計員應該很容易遵循。