本頁面由 Cloud Translation API 翻譯而成。

基本和介面

接著我們來定義 Tink 使用的語言、Primitive 和 Interface。

樸實

基元是對應所有演算法的數學物件安全地執行某些工作舉例來說，AEAD 基元包含可滿足 Tink 需要的安全性屬性的加密演算法一個 Aead

我們認為，基本功能不受程式設計語言或特定 CANNOT TRANSLATE 存取這些內容相反地，他們應該將基數視為數學物件舉例來說，如果我們考慮 AEAD 由多個函式組成，一個會執行加密執行解密作業

介面

介面是讓使用者存取原始程式碼的方式。舉例來說，我們預計日後 Tink 會提供 Mac 介面、以及 StreamingMac 介面，可用於計算資料不會直接載入記憶體

請注意，我們明確區分了介面和基本功能。這應該清楚說明這兩個介面提供給存取權相同。

正式定義

對大多數讀者來說，上述直觀說明應該已足夠。然而，我們也認為在提供正式語氣前，這些概念的定義

加密編譯函式

加密編譯函式的概念並不重要但需要進一步介紹，才能正式定義基元

加密編譯函式

加密函式是對應項目

\[ f: {\bf K} \times {\bf R} \times {\bf I} \to {\bf O}\]

從集合中 \({\bf K}\) (鍵空間)、 \({\bf R} = \{0,1\}^{\infty}\) (隨機性，我們假設為無限位元字串組合)；以及將 \({\bf I}\) (輸入空間) 設定為一組 \({\bf O}\) (輸出空間)。

稍後會更清楚說明為何我們加入了特定隨機性參數。

舉例來說，我們會展示這些概念 AES-GCM。針對每個有效鍵大小 \(s_k\)、Nonce 大小 \(s_n\)和代碼大小 \(s_t\)，AES-GCM 包含兩種加密編譯函式，一項另一個用於解密兩者的索引鍵空間相同 \({\bf K} = \{0,1\}^{s_k}\)。

以加密函式 \(\mathrm{Enc}\)來說，第 \(s_n\) 位元是隨機性參數來選取 Nonce

\({\bf B} = \{0,1\}^8\) 表示位元組。加密函式的輸入空間是 \({\bf I} = {\bf B}^{*} \times {\bf B}^{*}\) 任意長度的位元組字串組合成對。配對的第一個元素是用來做為訊息，第二個元素是關聯資料AES-GCM 標準但我們希望允許任意長度錯誤符號 \(\bot\) 並傳送至輸出空間。輸出空間會變為 \({\bf O} = {\bf B}^* \cup \{\bot\}\)，我們會任意定義因此必定能達到 \((\mathrm{IV} \| \mathrm{ciphertext} \| \mathrm{tag})\) 標準中所述的串連 \(\bot\)，以免某些輸入內容過長。因此，對於固定鍵加密函式會變成 \(\mathrm{Enc}_k : {\bf R} \times {\bf B}^* \times {\bf B}^* \rightarrow {\bf B}^* \cup \{\bot\}\)類型。

如果是解密函式， \(\mathrm{Dec}\) 金鑰空間則相同。輸入空間恰好是相同的： \({\bf I} ={\bf B}^* \times {\bf B}^*\)、但現在第一個元素是加密函式的輸出內容但第二天仍是相關聯的資料

輸出空間也剛好是相同的 \({\bf O} = {\bf B}^* \cup \{\bot\}\) (相同程度)。解讀方式略有不同 as \(\bot\) 通常表示驗證錯誤 (但也會是避免輸出內容過長)。

我們深知，上述正念並非將標準。舉例來說，您可以將 Nonce 視為輸入內容的一部分以隨機方式讀取 (結果會大同小異)。或者，您也可以將輸出內容定義為包含 Nonce 的三元。密文和標記 (而不是串連)。或者，將金鑰空間 (些許任意) \({\bf K} = \{0,1\}^{128} \cup \{0,1\}^{256}\)。

加密編譯演算法：

(對稱) 密碼編譯演算法是元組

\[(f_1, ... f_k)\]

所有函式都具有相同的金鑰空間。加密編譯演算法的 type 為元組 \((({\bf I}_1, {\bf O}_1), \ldots, ({\bf I}_k, {\bf O}_k))\)。

例如，針對每個鍵、Nonce 和標記的有效 \((s_k, s_n, s_t)\) 三元組而 AES-GCM\({}_{s_k, s_n, s_t}\) 是一款加密編譯演算法，兩項函式 \(\mathrm{Enc}\) 和 \(\mathrm{Dec}\) 上述範例。

基本和介面

接下來，我們要定義加密編譯基元。

樸實: 「基本」是一組加密編譯演算法，所有演算法都會透過此演算法相同類型 \((({\bf I}_1, {\bf O}_1), \ldots, ({\bf I}_k, {\bf O}_k))\)，演算法的鍵空間則互不相等。

舉例來說，如果 \(\mathrm{AEAD}\) 是 Tink 中的基元，這個鍵有多個演算法包括金鑰大小 128 和 256 位元的 AES-GCM，大小為 96 位元、具有某些金鑰大小的 AES-EAX，以及 XChaCha20Poly1305。他們擁有不連續的金鑰空格，但都會提供相同的加密編譯函式 \(\mathrm{Enc}\) 和 \(\mathrm{Dec}\)。(我們不會以某種方式發現目的在本次正式討論中收合不同金鑰大小的 AES-GCM，但當然可以)。

定義基元

一般的思考方式是先定義然後只考慮採用這類演算法

舉例來說，就 AEAD 而言， \(\mathrm{Dec}_k(\mathrm{Enc}_k(m, a), a) = m\) 為「always」滿意 (除非是純文字 \(m\) 。此外，我們也有安全性屬性；舉例來說這種加密機制可保證安全滴水不漏。

AEAD 基元是所有密碼編譯演算法的集合符合這些屬性實際上，當我們定義都是根據屬性加以定義我們不會提供每個演算法都會根據定義建議，

介面

Tink 中的「介面」可讓您在合理的情況下存取原始版本計算輸入空間中的輸出空間元素。例如：請考慮 Java 中的 AEAD 介面：

public interface Aead {
  byte[] encrypt(byte[] plaintext, byte[] associated_data) throws GeneralSecurityException;
  byte[] decrypt(byte[] ciphertext, byte[] associated_data) throws GeneralSecurityException;
}

請注意，我們不會授予隨機性的存取權。反之，我們允許使用者提供輸入空間的元素。不允許存取隨機性的情況如下：課程。¹

Tink 有時會針對單一基元提供多個介面。這項功能很實用，因為需求有時會有所不同。但是，這樣做通常會比價以及互通性舉例來說有些人以 Tink 編寫程式庫，因此使用者必須傳入 Aead 物件 (在內部加密內容)。如果 Tink 的產品數量過多和原始介面不同， \(\mathrm{AEAD}\) 可能性較高使用者沒有執行個體已就緒，可執行使用者選取的金鑰程式庫。因此需要新增更多介面。

AEAD 加密擁有已確認的防範選定的密文攻擊重複使用 NonceTink 中的 Aead 介面設計為禁止重複使用 Nonce：使用者不可提供 Nonce 做為加密的輸入內容。而是針對每個加密作業隨機產生新的 Nonce。 ↩