ASP.NET Core 中的子機碼衍生和驗證的加密
金鑰通道中的大部分金鑰都會包含某種形式的熵，而且會有演算法資訊，指出「CBC 模式加密 + HMAC 驗證」或「GCM 加密 + 驗證」。 在這些情況下，我們將內嵌的熵稱為此金鑰的主要金鑰處理資料 (簡稱 KM)，並執行金鑰衍生函數 (KDF) 來衍生將用於實際密碼編譯作業的金鑰。
注意
金鑰是抽象的，而且自訂實作的行為可能如下所示。 如果金鑰提供自己的 IAuthenticatedEncryptor 實作，而不是使用我們的其中一個內建處理站，本節所述的機制就不再適用。
額外驗證資料和子機碼衍生
IAuthenticatedEncryptor 介面可作為所有已驗證加密作業的核心介面。 其 Encrypt 方法會採用兩個緩衝區：plaintext 和 additionalAuthenticatedData (AAD)。 純文字內容會流式傳輸對 IDataProtector.Protect 的呼叫並且不進行任何變更，但 AAD 是由系統產生，由三個元件組成：
32 位元 magic 標頭 09 F0 C9 F0，用於識別此版本的資料保護系統。
128 位元金鑰識別碼。
由目的鏈結形成的可變長度字串，目的鏈接建立了執行這項作業的
IDataProtector。
由於 AAD 對於這三個元件的元組而言是唯一的，因此我們可以使用它從 KM 衍生新的金鑰，而不必在所有密碼編譯作業中都使用 KM 本身。 每次呼叫 IAuthenticatedEncryptor.Encrypt 時，就會進行下列金鑰衍生程式：
( K_E, K_H ) = SP800_108_CTR_HMACSHA512(K_M, AAD, contextHeader || keyModifier)
在這裡，我們會在計數器模式下呼叫 NIST SP800-108 KDF (請參閱 NIST SP800-108 第 5.1 節) 並採用下列參數：
金鑰衍生金鑰 (KDK) =
K_MPRF = HMACSHA512
label = additionalAuthenticatedData
context = contextHeader || keyModifier
內容標頭的長度可變，基本上可作為我們衍生 K_E 和 K_H 演算法的指紋。 金鑰修飾詞是每次呼叫 Encrypt 時隨機產生的 128 位元字串，可確保 KE 和 KH 對於此特定驗證加密作業具備唯一性的概率是壓倒性的，即使 KDF 的其他所有輸入都是常數。
針對 CBC 模式加密 + HMAC 驗證作業，| K_E | 是對稱區塊編碼器金鑰的長度，| K_H | 是 HMAC 常式的摘要大小。 針對 GCM 加密 + 驗證作業 | K_H | = 0。
CBC 模式加密 + HMAC 驗證
透過上述機制產生 K_E 之後，我們會產生隨機初始化向量，並執行對稱區塊編碼器演算法來加密純文字。 初始化向量和加密文字接著會透過 HMAC 常式 (已使用 K_H 金鑰初始化) 執行來產生 MAC。 此流程與傳回值會以圖形方式呈現於下方。
output:= keyModifier || iv || E_cbc (K_E,iv,data) || HMAC(K_H, iv || E_cbc (K_E,iv,data))
注意
IDataProtector.Protect 實作會在輸出的前面加上 magic 標頭和金鑰識別碼，再將它傳回給呼叫端。 因為 magic 標頭和金鑰識別碼是 AAD 的隱含部分，而且因為金鑰修飾元會當做 KDF 的輸入來提供，這表示 MAC 會驗證最終傳回承載的每一個位元組。
Galois/計數器模式加密 + 驗證
透過上述機制產生 K_E 之後，我們會產生隨機 96 位元 nonce，並執行對稱區塊編碼器演算法來加密純文字並產生 128 位元驗證標籤。
output := keyModifier || nonce || E_gcm (K_E,nonce,data) || authTag
注意
雖然 GCM 原生支援 AAD 的概念，但我們還是只將 AAD 饋送至原始 KDF，選擇將空字串傳遞至 GCM 作為其 AAD 參數。 原因有兩方面。 首先，為支援靈活度，我們永遠不想直接使用 K_M 作為加密金鑰。 其次，GCM 會對其輸入施加非常嚴格的唯一性要求。 以相同金鑰/nonce 對針對兩組或兩組以上不同輸入資料組叫用 GCM 加密常式的機率不得超過 2^-32。 如果我們固定 K_E，則我們執行的加密作業不能超過 2^32 次個，否則就會違反 2^-32 的上限。 這看起來可能是極大的作業數量，但高流量 Web 伺服器在短短幾天內就可能會處理 40 億個要求，此時這些金鑰在正常存留期內。 為了符合 2^-32 機率限制的規範，我們繼續使用 128 位元的索引鍵修飾元和 96 位元 nonce，這會大幅擴充任何給定 K_M 的可用作業計數。 為了簡化設計，我們在 CBC 和 GCM 作業之間共用 KDF 程式碼路徑，而且因為 KDF 中已考慮 AAD，因此不需要將它轉送至 GCM 常式。
