Tink 線路格式

本頁說明 Tink 的金鑰和原始輸出內容傳輸格式。 說明文件是以想加入其他語言的加密編譯者為目標， 其他高階加密編譯程式庫的 Tink 與維護人員，想要通過線路 相容模式。不適合一般大眾。

金鑰組序列化

Tink 使用 Google protobuf 將金鑰組序列化。

  • 二元序列化金鑰組是 tink.proto.索引鍵的 KeyData 值屬性為序列化 對應金鑰類型的 proto。
  • JSON 序列化金鑰組是採用 JSON 格式序列化的 Keyset proto。 請注意，KeyData 值仍是「二進位」序列化的 proto。
  • 加密金鑰組是序列化的 EncryptedKeyst proto，如 tink.proto.其中包含加密的二進位序列化金鑰組 以及選用部分未加密的 KeysetInfo 中繼資料

Tink 輸出前置字串

大部分的 Tink 基元都支援 5 位元組的輸出前置字串，包括：

  • 1 個位元組版本：0x01
  • 4 位元組鍵提示：這是所用金鑰的金鑰 ID。

某些舊版金鑰可能也支援版本位元組 0x00。

請注意，這個前置字串未經過驗證，且無法基於安全考量而使用 用途。Tink 會將其做為提示，加快解密或驗證速度。

AEAD

一般來說，Tink 會將 AEAD 密文格式化為：

prefix || IV || ciphertext || tag

除非對應的 RFC 中另行指定，否則將遭到忽略。prefix為空白 或是 5 位元組 Tink 輸出前置字串

AES-CTR-HMAC

針對 AES-CTR-HMAC，Tink 會使用相關資料 (AD) 計算 MAC，如下所示：

AD || IV || ciphertext || bitlen(AD)

其中 bitlen(AD) 是 AD 的長度 (以位元表示)，以 64 位元大端序表示 無正負號整數。這個 HMAC 配置遵循 AES-CBC-HMAC 的草稿 Mcgrew.

確定性 AEAD

Tink 針對 AES-SIV 實作 RFC 5297，呈現合成內容 。 原始版本可能會加上 5 位元組的 Tink 輸出前置字串。

雖然 RFC 5297 支援相關資料清單，但 Tink 只支援直接整合 一個相關聯的資料，對應至 RFC 5297 中一個元素的清單。 與空白相關聯的資料是含有一個空白元素 (非空白) 的清單 請參考閱讀清單，進一步瞭解 如何選擇 Kubeflow Pipelines SDK 或 TFX

串流 AEAD

請參閱 AES-CTR HMAC 和 AES-GCM-HKDF。

信封式加密

信封加密會使用資料加密金鑰「DEK」加密資料，該金鑰會使用 Tink 的 AEAD 基元。加密的運作方式如下：

  • 系統會使用指定的索引鍵範本 (或金鑰參數) 產生新的 DEK。
  • DEK 已序列化為位元組字串。序列化格式 金鑰類型 proto 的通訊協定緩衝區序列化。例如，這是 經過序列化的 AesGcmKey 通訊協定緩衝區訊息 aes_gcm.proto，適用於 AES GCM 的金鑰類型 DEK。 如要瞭解如何序列化，請參閱通訊協定緩衝區序列化。 通訊協定緩衝區
  • 序列化的 DEK 是由外部供應器 (例如 GCP) 加密。 轉換為 encrypted DEK。
  • DEK 是用來將包含相關資料的明文加密， ciphertext。因此 ciphertext 的格式與 AEAD 基元相同 對應於 DEK。

信封加密的輸出格式如下：

encrypted DEK length || encrypted DEK || ciphertext

encrypted DEK length 為 4 個位元組，會儲存 encrypted DEK 的長度 為 32 位元大端整數。

MAC

Tink 會遵循對應的 RFC。Primitives 可能會新增 5 位元組 Tink 輸出 前置字元。

PRF 組合

Tink 會遵循對應的 RFC。請注意，如果是 PRF 集的金鑰類型， 來自相同演算法的 MAC 金鑰類型，而非包含輸出長度。 PRF 設定金鑰一律不會新增 Tink 輸出前置字串。這可確保輸出 PRF

混合式加密

Tink 混合式加密的一般線路格式如下：

prefix || encapsulated_key || encrypted_data

prefix 為空白或 5 位元組 Tink 輸出前置字串。每個鍵類型都包含 瞭解要剖析的位元組數，以及如何剖析這些位元組中的 encapsulated_key。

HPKE (混合公開金鑰加密)

Tink 遵循 RFC 9180 定義的 HPKE 標準。 HPKE 加密套件包含以下三個基元。

  • 金鑰封裝機制 (KEM)
  • 金鑰衍生函式 (KDF)
  • 透過相關資料進行驗證加密 (AEAD)

HPKE 標準並未在 RFC 9180 10。Tink 的 HPKE 實作會使用以下程式碼 encapsulated_key 和 encrypted_data 值。

  • encapsulated_key
    • 傳送者的序列化公開金鑰
    • 在以下位置定義為 enc： RFC 9180 第 4.1 節
    • 格式取決於所使用的特定 HPKE KEM
  • encrypted_data
    • 密文和標記 (例如不含 IV 的 ciphertext || tag)
    • 在以下位置定義為 ct： RFC 9180 第 4 節
    • 格式取決於所用特定 HPKE AEAD
X25519 Diffie-Hellman 型 KEM

如果是 X25519 DHKEM，enc 的值就是傳送者的 32 位元組 Diffie-Hellman 公開值 鍵。

ECIES-AEAD-HKDF

對於 Tink 的 ECIES-AEAD-HKDF 實作，encapsulated_key 輸出內容為 金鑰封裝機制 (KEM) 和 encrypted_data 則是輸出內容 資料封裝機制 (DEM) 條款。

KEM

視金鑰類型而定，Tink 會使用經過壓縮和未壓縮的橢圓曲線 點，則遵循 RFC 8422/ANSI.X9-62.2005 編碼標準。適用對象 未壓縮點，位元組 0x04 後面接著 x 和 y 座標為固定大小的整數。如果是經過壓縮的座標，位元組 0x02 或 0x03 和 x 座標，做為固定大小的整數。針對 X25519， 並使用 RFC 7748 定義 (以 x 座標為固定大小的整數)。

鄧白氏環球編碼

如果是 encrypted_data，Tink 採用與 AEAD 相同的格式。這包括 並指定 IV。

金鑰衍生

系統會先計算共用點的 x 座標 x_ss。索引鍵 然後將 AEAD 設為：

HKDF(ikm = encapsulated_key || x_ss, salt = salt_of_key, info = context_info, length = dem_key_size)

其中 encapsulated_key 是以位元組為單位的完整 KEM 輸出內容。

數位簽章

Tink 會遵循對應的 RFC。Primitives 可能會新增 5 位元組 Tink 輸出 前置字串設為產生的代碼。

ECDSA

視金鑰中的 EcdsaSignatureEncoding 欄位而定， ECDSA 簽章的格式為 IEEE P1363 或 ASN.1 DER。

IEEE P1363 簽名的格式為 r || s，其中 r 和 s 是 加上零填充值，且大小 (以位元組為單位) 與曲線順序相同。適用對象 例如，如果是 NIST P-256 曲線，r 和 s 都會填補至 32 個位元組。

DER 簽名是利用 ASN.1 編碼：

ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }

尤其是編碼方式如下：

0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s

Tink 遵循簽章驗證的最佳做法，僅接受 DER 編碼的 ECDSA 簽章 (其他 BER 編碼的簽名無效)。

這有助於防範特徵碼可削性攻擊，這類攻擊通常受到影響 加密貨幣系統