如果 BLAKE2 只有 256/512 位,BLAKE2X 是否適合生成具有任何安全性的密鑰事件?
我可以使用以下方案從具有足夠熵的隨機源中使用任何雜湊函式生成任何安全性的密鑰:
H(00||小號)||H(01||小號)||H(02||小號)||H(03||小號)||⋯$$ H(00||S) || H(01||S) || H(02||S) || H(03||S) || \cdots $$
/\ H 是雜湊,S 是種子,00、01、02 是計數器。
BLAKE2X 雜湊計算如下:
B2(0,64,H0)‖B2(1,64,H0)‖…‖B2(⌊ℓ/64⌋,ℓmod64,H0)$$ \operatorname{B2}(0,64,H_0)\mathbin|\operatorname{B2}(1,64,H_0)\mathbin|\ldots\mathbin|\operatorname{B2}(\lfloor\ell/64\rfloor,\ell\bmod64,H_0) $$
/\ B2(i,j,X) $ B2(i,j,X) $ 是具有節點偏移量i和摘要長度j的X $ X $ 的散列。i $ i $ j $ j $
這兩個方案看起來很相似,所以我有一個問題。
BLAKE2X 是否適合生成比底層雜湊函式 (BLAKE2) 的內部狀態具有更多安全位的密鑰,如H(00||S)||H(01||S)||H(02||S)||H(03||S)||⋯ $ H(00||S) || H(01||S) || H(02||S) || H(03||S) || \cdots $ 是否帶有任何雜湊函式?
PS:我指的是任何不易受到長度擴展攻擊的雜湊函式。
BLAKE2X 可用於從合適的安全輸入生成任意密鑰材料。也就是說,它可以安全地用作最多 4 GiB 數據的密鑰派生函式。
但是,這種密鑰派生函式的安全性受限於輸入的熵和 BLAKE2 實例的狀態大小。例如,如果你的種子中只有 32 位的熵,那麼構造的安全性也只有 32 位。同樣,BLAKE2Xb 不能提供超過 512 位的安全性,BLAKE2Xs 也不能提供超過 256 位的安全性,因為這些是它們內部狀態大小的限制。
不過幸運的是,這不是問題,因為 256 位安全性預計在無限期的未來都是安全的。只要您選擇了具有適當熵的種子(例如,您的系統 CSPRNG 或安全的 Diffie-Hellman 密鑰交換,無論是否為 EC),您就無需擔心。
我們使用密鑰派生函式生成更大輸出的實際原因是有時我們需要更大量的密鑰材料。例如,TLS 和 SSH 都需要加密密鑰、隨機數,還可能需要雙向的 MAC 密鑰,這應該是不相關的,加起來可能超過 1024 字節,但整個連接的安全性可能不會超過 128 或 256 位(由於密鑰交換)。同樣,將 Curve448 密鑰的種子擴展到它的兩個私有組件中需要大量輸出,但不超過 224 位安全性。
從技術上講,您首先提到的結構不會像 BLAKE2X 那樣受到內部狀態大小的限制。然而,正如我提到的,這只是理論上的考慮,因為 BLAKE2X 提供了完全足夠的安全狀態。HKDF 使用結構相似的方法(提取和擴展),用於 TLS 1.3,被認為是健壯和安全的。