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.