AES-GCM-HKDF 串流 AEAD

本文件正式定義了 AES-GCM-HKDF 串流金鑰表示的數學函式，以 proto 格式編碼為 type.googleapis.com/google.crypto.tink.AesGcmHkdfStreamingKey。

這種加密方式大部分是以 HRRV15¹ 為基礎。在進行安全性分析時，我們使用 HS20²。

鍵與參數

索引鍵分為下列幾個部分 (本文件中的所有大小均以位元組為單位)：

• \(\mathrm{KeyValue}\)，位元組字串。
• \(\mathrm{CiphertextSegmentSize} \in \{1, 2, \ldots, 2^{31}-1\}\)。
• \(\mathrm{DerivedKeySize} \in \{16, 32\}\)。
• \(\mathrm{HkdfHashType} \in \{\mathrm{SHA1}, \mathrm{SHA256}, \mathrm{SHA512}\}\)。

有效金鑰還符合下列屬性：

• \(\mathrm{len}(\mathrm{KeyValue}) \geq \mathrm{DerivedKeySize}\)。
• \(\mathrm{CiphertextSegmentSize} > \mathrm{DerivedKeySize} + 24\) (相當於 \(\mathrm{len}(\mathrm{Header}) + 16\) 稍後說明的情況)。

在剖析金鑰或建立對應的基元時，Tink 會拒絕違反這些屬性的金鑰。

加密函式

為了使用 \(\mathrm{Msg}\) 關聯資料\(\mathrm{AssociatedData}\)加密訊息，我們會建立標頭，將訊息拆分為多個區段、加密每個區段，然後再將加密區段串連起來。

建立標頭

我們會挑選長度為 \(\mathrm{Salt}\) 長度\(\mathrm{DerivedKeySize}\) 的統一隨機字串，以及長度為 7 的統一隨機字串 \(\mathrm{NoncePrefix}\)。

接著設定 \(\mathrm{Header} := \mathrm{len}(\mathrm{Header}) \| \mathrm{Salt} \| \mathrm{NoncePrefix}\)，將標頭長度編碼為單位元組。請注意， \(\mathrm{len}(\mathrm{Header}) \in \{24, 40\}\)。

接著，使用 HKDF³ 搭配 \(\mathrm{HkdfHashType}\)、input \(\mathrm{ikm} := \mathrm{KeyValue}\)、 \(\mathrm{salt} := \mathrm{Salt}\)和 \(\mathrm{info} := \mathrm{AssociatedData}\)提供的雜湊函式，輸出長度 \(\mathrm{DerivedKeySize}\)。我們將結果稱為 \(\mathrm{DerivedKey}\)。

拆分訊息

此訊息 \(\mathrm{Msg}\) 將分成多個部分： \(\mathrm{Msg} = M_0 \| M_1 \| \cdots \| M_{n-1}\)。

可選擇的長度如下：

• \(\mathrm{len}(M_0) \in \{0,\ldots, \mathrm{CiphertextSegmentSize} - \mathrm{len}(\mathrm{Header}) - \mathrm{16}\}\)。
• 若為 \(n>1\)，則 \(\mathrm{len}(M_1), \ldots, \mathrm{len}(M_{n-1}) \in \{1,\ldots, \mathrm{CiphertextSegmentSize} - \mathrm{16}\}\)。
• 如果為 \(n>1\)，則 \(\mathrm{len}(M_{0}), \ldots, \mathrm{len}(M_{n-2})\) 必須符合上述限制的長度上限。

\(n\) 最多 \(2^{32}\)。否則加密會失敗。

將區塊加密

為加密區段 \(M_i\)，我們會計算 \(\mathrm{IV}_i := \mathrm{NoncePrefix} \| \mathrm{i} \| b\)， \(\mathrm{i}\) 在大端序編碼中為 4 個位元組，如果 $i < n-1$ 和 0x01 則使用 0x00 位元組 $b$。

然後我們加密 \(M_i\) 使用 AES-GCM⁴ ，其中的關鍵是\(\mathrm{DerivedKey}\)，初始化向量是 \(\mathrm{IV}_i\)，且關聯資料為空字串。 \(C_i\) 是這種加密的結果（即串聯 \(C\) 和 \(T\) 在連結的 AES-GCM 參考的第 5.2.1.2 節中）。

串連加密區段

最後，所有區段都會串連為 \(\mathrm{Header} \| C_0 \| \cdots \| C_{n-1}\)，也就是最終的密文。

解密

解密會反向解密加密。我們會使用標頭取得\(\mathrm{NoncePrefix}\)，並分別解密每個密文區段。

API 能夠 (且通常確實) 允許隨機存取，或存取檔案開頭而不檢查檔案結尾。這是刻意設計，因為可以從 \(C_i\)解密 \(M_i\) ，而不會解密所有先前和剩餘的密文區塊。

不過，請務必小心，不要讓使用者混淆檔案結尾和解密錯誤：不論是哪一種情況，API 都可能需要傳回錯誤，而忽略差異將導致對手能夠有效截斷檔案。

金鑰的序列化與剖析

為了將金鑰序列化為「Tink Proto」格式，我們會先以明顯的方式將參數對應至透過 aes_gcm_hkdf_streaming.proto 提供的 proto，version 欄位必須設為 0。然後，我們會使用一般的 Proto 序列化進行序列化，然後將產生的字串嵌入 KeyData 原型的欄位值中。我們將 type_url 欄位設為 type.googleapis.com/google.crypto.tink.AesGcmHkdfStreamingKey。接著，我們將 key_material_type 設為 SYMMETRIC，並將其嵌入金鑰組。我們通常會將 output_prefix_type 設為 RAW。例外狀況是，如果剖析金鑰時使用的 output_prefix_type 值不同，Tink 可能會寫入 RAW 或先前的值。

為剖析金鑰，我們會反向執行上述程序 (剖析原型時如往常)。系統會忽略欄位 key_material_type。您可以忽略 output_prefix_type 的值，或是拒絕 output_prefix_type 與 RAW 不同的鍵。version 與 0 不同的金鑰必須遭到拒絕。

已知問題

實作上述加密函式不應成為安全的分支，請參閱分支安全相關說明。

參考資料