Tink 是 Google 的加密編譯工具和安全性工程師所編寫的開放原始碼密碼學程式庫。Tink 提供安全又簡單的 API，可透過以使用者為中心的設計、謹慎的實作與程式碼審查，以及廣泛的測試，進而減少常見的錯誤。如要進一步瞭解 Tink 用於達成哪些目標，請參閱本頁的「目標」一節。
Tink 可協助沒有密碼編譯背景的使用者安全地實作常見的密碼編譯工作。Google 已部署數百個產品和系統中的 Tink。
使用 Tink 的好處
使用 Tink 最重要的理由如下：
簡單易用
密碼素描很難出錯。有了 Tink，您只要編寫幾行程式碼，就能透過內建安全保證加密或簽署資料。Tink 也可協助您使用外部金鑰管理系統 (KMS) 輪替金鑰或安全金鑰。
安全無虞
在 BoringSSL 和 Java Cryptography Architecture 等知名程式庫上增添安全性保護措施，並直接顯示在介面中，讓稽核員和工具能快速找出缺口。Tink 也會將可能危險的 API 分開，方便您監控 API。
適用於
Tink 密文與現有的密碼編譯程式庫相容。Tink 也支援在 Amazon KMS、Google Cloud KMS、Android KeyStore 和 iOS 鑰匙圈中加密或儲存金鑰。
誰正在使用 Tink？
Tink 廣受許多公司採用，包括 Google、Square 和 Citadel，以及數百家 Google Cloud 客戶和 Google Pay 合作夥伴。Tink 也提供 Jetpack Security 程式庫，可保護許多熱門 Android 應用程式，例如 Slack、Adidas、AirBnb 和 Nextdoor。
Tink 目標
與其他加密編譯程式庫相比，Tink 的主要目標是什麼？Tink 用來達成這些目標的主要機制為何？
簡單來說，Tink 有兩個目標：
- 提倡加密編譯的靈活性：使用者應能夠輕鬆變更金鑰和演算法。
- 啟用安全性審查：Tink 的設計宗旨是讓使用者編寫程式碼，可以在本機接受安全性審查，這個程式碼可提供清楚的安全性保證。
Tink 用來達成這些目標的主要機制如下：
- Tink 提供基本和介面，做為重要的抽象層。這些抽象化機制可讓使用者撰寫程式碼，並未指定要使用的確切演算法，而是指定預期的安全性標記。
- Tink 使用「金鑰組」的概念，這是與特定基元相關聯的一組鍵。如此一來，使用者就會編寫支援多個金鑰的程式碼。
- 在 Tink 中，金鑰不只由基礎金鑰內容指定，也是加密編譯演算法和所有參數。這表示 Tink 金鑰一律會從所有可能存在的函式中選取不重複的加密編譯函式，而沒有空間進行解讀。
以下各節將詳細說明這些概念。
加密編譯靈活性
請考慮使用 Google 軟體工程團隊，這本電子書介紹在軟體工程領域中學到的教訓，並附帶「從程式設計期間學到的教訓」副標題。在這個例子中，作者會竭盡所能，隱瞞著事情變革會帶來的影響。這項事實也影響了 Tink 的許多設計。在密碼編譯方面 請務必為變更做好準備金鑰將會洩露，演算法也會損毀。對許多使用者來說，能夠切換金鑰和演算法十分重要，且做好萬全的準備工作更是如此。
安全性審查和本機房源
Tink 鼓勵使用介面 (例如 AEAD 介面) 可讓使用者加密資料。在其他安全性保證中，AEAD 可以保證對同一字串進行多次加密會產生不同的密文。
想瞭解如何使用這種 ID，假設工程師想將一些機密 ID 儲存在使用者 Cookie 中，他們可能會提供以下類別：
class IdEncrypter {
public static IdEncrypter createFromAead(Aead aead);
public String encrypt(long id) throws GeneralSecurityException;
public long decrypt(String encrypted) throws GeneralSecurityException;
};
傳遞 Aead 可取得下列屬性：
- 程式碼會傳達
IdEncrypter執行工作時，需要與Aead提供的安全性屬性加密配置。而且DeterministicAead也不例外；IdEncrypter規定同一個 ID 的兩項加密設定不同。另一方面，將 AES GCM 加密工具 (一個Aead的一個執行個體) 做為參數使用的做法會太過嚴格：任何 Aead 都足以讓IdEncrypter執行工作，而且不需要一個特定演算法。 - 進行安全性審查時，我們會將這一點納入考量。安全性審查人員不需要瀏覽所有程式碼存放區，藉此確認是否有人所製作的
Aead子類別，而這並不適合與IdEncrypter搭配使用。相反地，Tink 會提供所有 Aead 物件擁有的安全屬性，審查人員可以檢查這些屬性是否足夠。
而第二點特別需要注意。使用者經常要求新增演算法，而這些演算法「不太」Aead。以上要點說明這具有危險的原因：如果有任何實作的 Aead 未提供必要安全性保證，IdEncrypter 可能會變得不安全，而執行安全性審查的工程師必須檢查其他程式碼，才能確認物件是否已正確執行個體化。