從隨機的 128 個 nonces 和一個秘密的 512 主密鑰推導許多 (Key, IV) 對

ext4 加密系統使用 aes-256-xts 加密文件。每個文件使用兩個唯一的密鑰，這些密鑰源自一個 512 位主密鑰和一個在創建文件時隨機生成的每個文件的 128 位隨機數（請參閱設計文件）。

為了為每個文件派生兩個 256 位密鑰，512 位主密鑰使用 AES-128-ECB 加密，使用 128 隨機數作為密鑰。

設計文件中指出的一個缺點是，如果文件密鑰被洩露，那麼攻擊者可以通過使用 nonce 解密文件密鑰來檢索主密鑰。

我的問題是：為什麼不使用單向 KDF 來派生每個文件的密鑰呢？我會使用類似的東西派生密​​鑰：

key1||key2 = hmac_sha512(master_key, nonce)

這種方法有什麼缺點嗎？

我們是否可以假設主密鑰是統一選擇的？正如HKDF 論文所定義的，KDF 的目標是：

它的目標是獲取初始密鑰材料的來源，通常包含一定數量的隨機性，但不是均勻分佈的，或者攻擊者對它有一些部分了解，並從中派生出一個或多個密碼學上的強密鑰。我們將“加密強”密鑰的概念與偽隨機密鑰的概念相關聯，即通過可行計算與相同長度的隨機統一字元串無法區分。

如果主密鑰是均勻隨機選擇的，則不需要完整的 HKDF 提取和擴展範式；我們所需要的只是擴展階段，它可以通過具有統一密鑰的 PRF 來實現。

鑑於 HMAC-SHA512 的 PRF 安全性，您對它的使用看起來很合適，但可能是矯枉過正，因為：

• HMAC 支持可變輸入長度，但此應用程序具有固定的輸入和輸出大小；
• 該應用程序已經在使用 AES，因此引入 HMAC 需要一個額外的原語。

所以也許更簡單的是：

1. 直接使用較短的 256 位主密鑰作為 AES 密鑰；
2. 給定文件的 random nonce，將文件密鑰導出為fk = fk[1] || fk[2] || fk[3] || fk[4]，其中：

• fk[0] = random_nonce;
• fk[i] = AESENC(master_key, fk[i-1]).

這相當於在 OFB 或 CBC 模式下使用隨機 IV 加密全零明文，因此針對這種方法的攻擊應該減少為針對這些模式的攻擊。因此，例如，如果某些文件密鑰按照您的建議洩露，那就是已知的明文攻擊場景。

作為一個真實的例子，目前的 AES- GCM -SIV 草案（draft-irtf-cfrg-gcmsiv-02

if len(key-generating-key) == 16 {
 record-authentication-key = AES128(key = key-generating-key, input = nonce)
 record-encryption-key = AES128(key = key-generating-key,
                                input = record-authentication-key)
} else if len(key-generating-key) == 32 {
 record-authentication-key = AES256(key = key-generating-key, input = nonce)
 second-half = AES256(key = key-generating-key, input = record-authentication-key)
 first-half = AES256(key = key-generating-key, input = second-half)
 record-encryption-key = concatenate(first-half, second-half)
}

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