Cohérence

Il est important que Tink se comporte de la même manière dans tous les langages de programmation. Ce concept n'est pas simple, mais surtout :

Pour assurer la cohérence, Tink utilise des tests multilingues disponibles dans le dépôt GitHub multilingue. Ces tests vérifient la cohérence et l'interopérabilité des différents langages.

Cependant, définir la cohérence n'est pas aussi simple qu'on pourrait le penser. Cette page fournit donc notre définition de travail. En gros, Tink fournit deux types de cohérence :

Contexte

De manière générale, Tink fournit les API suivantes :

  • Manipulation d'un jeu de clés : Tink fournit des API permettant d'ajouter des clés à un jeu de clés, d'en supprimer et de modifier la clé primaire d'un jeu de clés.

  • Sérialisation d'un jeu de clés : Tink fournit des API permettant de sérialiser un jeu de clés en une séquence d'octets et, inversement, d'analyser un jeu de clés à partir d'une séquence d'octets.

  • Création de primitives : Tink fournit une API permettant de créer une interface pour une primitive à partir d'un jeu de clés. Par exemple, pour créer un objet Aead à partir d'un ensemble de clés en Java, l'utilisateur appelle keysetHandle.getPrimitive(config, Aead.class).

  • Utilisation de la primitive : l'interface produite lors de l'étape de création de la primitive fournit une API permettant d'effectuer des opérations cryptographiques.

Il y a deux questions importantes à se poser concernant ces API :

  • Création : pour un ensemble de clés, un langage et une primitive sérialisés donnés, est-il possible de créer la primitive à partir de cet ensemble de clés dans le langage ?

  • Évaluation : Si une primitive peut être créée dans un langage à partir d'un jeu de clés donné, comment l'objet primitif se comporte-t-il ?

Il est important de noter que Tink ne fournit pas de cohérence lors de l'analyse d'un jeu de clés. Par exemple, il est possible que Tink C++

  • analyse correctement les ensembles de clés contenant des clés CHACHA20-POLY1305, même si les opérations AEAD CHACHA20-POLY1305 ne sont pas implémentées dans Tink ;
  • analyse correctement les ensembles de clés avec des clés d'une longueur de 1 octet, ce qui échouera dans toutes les opérations cryptographiques.

Ces comportements peuvent changer dans les versions mineures.

Cohérence de l'évaluation

La cohérence de l'évaluation est plus importante que toute cohérence dans le processus de création : si un AEAD en Java ne peut pas déchiffrer le chiffrement de l'AEAD en C++, les utilisateurs rencontrent un problème sérieux.

En général, Tink vise à être cohérent de manière évidente pour les primitives. Par exemple, si un binaire C++ calcule une signature avec public_key_sign->Sign(data), l'appel de validation Java correspondant publicKeyVerify.verify(signature, data) devrait réussir.

Cependant, même dans ce cas, il existe quelques mises en garde. Par exemple, le type renvoyé de aead.Encrypt en Java est un byte[]. Conformément à la spécification du langage Java (JLS) §10.7, la longueur d'un tableau est de type int, qui, conformément à la section §JLS 4.2.1, peut être de 2147483647 au maximum. Par conséquent, le chiffrement d'un tableau d'une longueur de 2 147 483 647 échoue en Java : le chiffrement entraîne une surcharge, ce qui signifie que la sortie serait trop longue. Néanmoins, dans d'autres langages, le chiffrement est autorisé pour ces entrées.

Par conséquent, Tink assure la cohérence de l'évaluation : pour un jeu de clés donné, si la création de la primitive réussit dans deux langages, ils se comportent de la même manière.

Toutefois, certaines opérations peuvent échouer dans des circonstances exceptionnelles.

Cohérence de la création

La création de primitives ne réussit pas toujours pour tous les ensembles de clés. Par exemple, Tink n'autorise pas les utilisateurs à créer une clé AesSivKey si le matériel de clé a une longueur de 128 bits.

Néanmoins, Tink assure la cohérence comme suit : si deux langages sont compatibles avec un type de clé, l'ensemble de clés pour lequel la primitive peut être créée coïncide. Bien entendu, si un langage n'est pas compatible avec un type de clé, aucun objet primitif ne peut être créé.

La cohérence de la création est moins importante que celle de l'évaluation, et il existe plus d'exceptions à cette règle que pour la cohérence de l'évaluation. Ces limites sont documentées dans notre liste des types de clés compatibles. Par exemple, pour le type de clé ECIES, Tink propose de choisir la courbe elliptique à utiliser pour l'accord de clé, mais Java n'est pas compatible avec X25519. Par conséquent, la création d'une clé à l'aide de X25519 en Java échoue.

  1. Dans ce document, nous utilisons le terme Keyset pour désigner l'objet appelé KeysetHandle dans la plupart des langages. ↩