Dans de nombreuses bibliothèques cryptographiques, les clés ne sont souvent identifiées que par certaines séquences d'octets. Prenons l'exemple de fonctions OpenSSL telles que EVP_EncryptInit_ex, qui (en dehors des octets de clé), a également besoin de l'IV pour le calcul, ou de la méthode javax.crypto Cipher.init, qui utilise à la fois une séquence de clés et un AlgorithmParameterSpec. Ces fonctions sont souvent difficiles à utiliser correctement, et la transmission de paramètres incorrects peut avoir de graves conséquences.
L'objectif de Tink est différent. Il attend qu'une clé se compose toujours à la fois du matériel de clé et des métadonnées (les paramètres).
Une clé AEAD complète, par exemple, spécifie précisément le fonctionnement du chiffrement et du déchiffrement. Les deux fonctions \(\mathrm{Enc}\) et\(\mathrm{Dec}\)sont spécifiées, ainsi que le mode d'encodage du texte chiffré (par exemple, le vecteur d'initialisation, le chiffrement et le tag).
Dans Tink, une clé AES est non seulement une séquence d'octets de 128, 192 ou 256 bits, mais elle stocke également les spécifications d'algorithme correspondantes nécessaires au calcul de la clé, sous la forme d'un objet paramètres. Par conséquent, une clé AES-EAX complète et une clé AES-GCM complète sont des objets différents dans Tink.