What is Tink?

Tink is an open-source cryptography library written by cryptographers and security engineers at Google. Tink's secure and simple APIs reduce common pitfalls through user-centered design, careful implementation and code reviews, and extensive testing. See the Goals section on this page for more insight into which objectives Tink was designed to fulfil.

Tink helps users without a cryptography background safely implement common cryptographic tasks. At Google, Tink has been deployed in hundreds of products and systems.

Why should I use Tink?

The most important reasons to use Tink are:

  • It's simple to use

    Cryptography is difficult to get right. With Tink, you can encrypt or sign data with built-in security guarantees using just a few lines of code. Tink can also help you rotate keys or secure keys using external Key Management Systems (KMSs).

  • It's secure

    Tink adds security protections on top of well known libraries like BoringSSL and Java Cryptography Architecture and shows them right in the interfaces, so auditors and tools can quickly find gaps. Tink also separates APIs that are potentially dangerous, so you can monitor them.

  • It's compatible

    Tink ciphertexts are compatible with existing cryptography libraries. Tink also supports encrypting or storing keys in Amazon KMS, Google Cloud KMS, Android Keystore, and iOS Keychain.

Who's using Tink?

Tink is widely used by many companies, including Google, Square, and Citadel, as well as hundreds of Google Cloud customers and Google Pay partners. Tink also powers the Jetpack Security library, which secures many popular Android apps like Slack, Adidas, AirBnb, and Nextdoor.

Tink Goals

What are the main goals of Tink compared to other cryptographic libraries, and what are the main mechanisms which Tink uses to achieve these goals?

In short, Tink has two goals:

  1. Promote cryptographic agility: Users should be able to change keys and algorithms in a simple way.
  2. Enable security reviews: Tink aims to allow users to write code whose security can be reviewed locally, by providing interfaces which give clear security guarantees.

The main mechanisms Tink uses to achieve these goals are as follows:

  1. Tink provides primitives and interfaces as important abstractions. These abstractions allow users to write code which does not specify the exact algorithm to be used, but instead specifies the expected security notion.
  2. Tink uses the notion of a "keyset", which is a set of keys that are associated with a particular primitive. This results in users writing code which works with multiple keys.
  3. In Tink, keys are not only specified by the underlying key material, but also the cryptographic algorithm, as well as all parameters. This means that a Tink key always selects a unique cryptographic function from all possible functions which can exist, and leaves no room for interpretation.

The following sections explain these concepts in more detail.

Cryptographic agility

Consider Software Engineering at Google, a book about lessons learned in the field of software engineering, with the subtitle "lessons learned from programming over time". In it, the authors go to great lengths to implore the implications of the fact that things change. This fact also impacted much of the design of Tink. In cryptography, it is important that one prepares for change. Keys will leak, and algorithms will be broken. Being able to switch out keys and algorithms is crucial for many users, and being prepared is prudent.

Security reviews and local properties

Tink promotes the use of interfaces, such as our AEAD interface, which allows users to encrypt data. Among other security guarantees, an AEAD guarantees that multiple encryptions of the same string result in different ciphertexts.

To see how this can be used, suppose an engineer wants to store some sensitive ID in a user cookie. They might provide a class such as this:

class IdEncrypter {
  public static IdEncrypter createFromAead(Aead aead);

  public String encrypt(long id) throws GeneralSecurityException;
  public long decrypt(String encrypted) throws GeneralSecurityException;
};

Passing an Aead obtains the following properties:

  1. The code communicates that for IdEncrypter to do its job, it requires an encryption scheme with the security properties an Aead provides. Alternatively, a DeterministicAead wouldn't be enough -- the IdEncrypter requires that two encryptions of the same id are different. On the other hand, taking as parameter an instance of an AES GCM encrypter (one particular instance of an Aead) would be overly strict: any Aead is enough for IdEncrypter to do its job, and it does not need to be one specific algorithm.
  2. A security review can take this point into account. A security reviewer does not need to go through all of the entire code repository to check if somewhere, someone made a subclass of Aead which is not secure for use with IdEncrypter. Instead, Tink provides security properties which all Aead objects have, and the reviewer can check that these are sufficient.

In particular the second point requires a lot of care. Users often ask to add algorithms which are 'not quite' an Aead. The previous point illustrates why this is dangerous: if there is any implementation of Aead available which does not provide the required security guarantees, IdEncrypter can become insecure, and the engineer performing a security review needs to examine additional code to check that the object is instantiated correctly.