In many cryptographic libraries, keys are often identified by only some byte sequences. Consider for example OpenSSL functions such as EVP_EncryptInit_ex, which apart from the key bytes, also needs the IV for computation; or the javax.crypto method Cipher.init, which takes both a key sequence and an AlgorithmParameterSpec. Such functions are often difficult to use correctly and passing the wrong parameters can have serious consequences.

Tink aims to be different, and expects a key to always consist of both the key material and the metadata (the parameters).

A full AEAD key for example specifies in exact detail how encryption and decryption works - it specifies the two functions \(\mathrm{Enc}\) and \(\mathrm{Dec}\), and how the ciphertext is encoded (e.g. initialization vector, followed by the encryption, followed by the tag).

An AES key in Tink is not only a byte sequence of length 128, 192 or 256 bits, but it also stores the corresponding algorithm specifications needed to compute the key, in the form of a parameters object. Hence, a full AES-EAX key and a full AES-GCM key are different objects in Tink.