Dans de nombreuses bibliothèques cryptographiques, les clés ne sont souvent identifiées que par certaines séquences d'octets. Prenons l'exemple des fonctions OpenSSL telles que EVP_EncryptInit_ex, qui, en plus des octets de clé, a également besoin de l'IV pour le calcul ; ou la méthode javax.crypto Cipher.init, qui accepte à la fois une séquence de clés et un AlgorithmParameterSpec. Ces fonctions sont souvent difficiles à utiliser correctement, et transmettre les mauvais paramètres peut avoir de graves conséquences.
Tink vise à être différent et s'attend à ce qu'une clé soit toujours composée à la fois du matériel de clé et des métadonnées (les paramètres).
Par exemple, une clé AEAD complète spécifie précisément le fonctionnement du chiffrement et du déchiffrement. Elle spécifie les deux fonctions \(\mathrm{Enc}\) et\(\mathrm{Dec}\), ainsi que la façon dont le texte chiffré est encodé (par exemple, vecteur d'initialisation, suivi du chiffrement, suivi de la balise).
Une clé AES dans Tink n'est pas seulement une séquence d'octets de 128, 192 ou 256 bits, mais elle stocke également les spécifications de l'algorithme correspondant nécessaires pour calculer la clé, sous la forme d'un objet parameters. Par conséquent, une clé AES-EAX complète et une clé AES-GCM complète sont des objets différents dans Tink.