Régularité

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 maintenir la cohérence, Tink utilise des tests multilingues disponibles dans le dépôt GitHub multilingue. Ces tests permettent de vérifier la cohérence et l'interopérabilité de différents langages.

Cependant, définir la cohérence n'est pas aussi simple qu'on pourrait s'y attendre. Par conséquent, cette page fournit notre définition fonctionnelle. Fondamentalement, Tink fournit deux types de cohérence:

Contexte

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

  • Manipulation d'une collection de clés:Tink fournit des API permettant d'ajouter de nouvelles clés à une collection de clés, de supprimer des clés d'une collection et de modifier la clé primaire d'une collection.

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

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

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

Il y a deux questions importantes à vous poser au sujet de ces API:

  • Création:pour une collection de clés, une langue et une primitive sérialisées, est-il possible de créer la primitive à partir de cette collection dans le langage ?

  • Évaluation:si une primitive peut être créée dans une langue à partir d'une collection de clés donnée, comment se comporte-t-elle ?

Il est important de noter que Tink n'offre pas de cohérence lors de l'analyse d'une collection de clés. Par exemple, il est possible que Tink C++

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

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 parvient pas à déchiffrer le chiffrement du AEAD en C++, les utilisateurs rencontrent un problème sérieux.

En règle générale, Tink cherche à ê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 aboutir.

Toutefois, même ici, il y a quelques mises en garde. Par exemple, le type renvoyé de aead.Encrypt en Java est byte[]. Conformément au paragraphe 10.7 du paragraphe 10.7 du langage Java (JLS, Java Language Specification), la longueur d'un tableau est de type int, dont la longueur maximale est de 2 147 483 647 selon la norme §JLS 4.2.1. 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 peut réussir pour de telles entrées.

Par conséquent, Tink assure la cohérence de l'évaluation : pour une collection de clés donnée, si la création de la primitive aboutit dans deux langages, le comportement est le même.

Il existe toutefois une exception : certaines opérations peuvent échouer dans des circonstances exceptionnelles.

Cohérence des créations

La création de primitives ne réussit pas toujours pour l'ensemble des jeux de clés. Par exemple, Tink ne permet pas aux utilisateurs de créer une clé AesSivKey si le matériel de la clé a une longueur de 128 bits.

Néanmoins, Tink assure la cohérence de la façon suivante: si deux langages prennent en charge un type de clé donné, l'ensemble de clés pour lesquelles la primitive peut être créée se coincide. Bien entendu, si une langue 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 la cohérence de l'évaluation, et il existe plus d'exceptions à cette règle que la cohérence de l'évaluation. Ces limites sont documentées dans la liste des types de clés compatibles. Par exemple, pour le type de clé ECIES, Tink permet 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é utilisant X25519 en Java échoue.

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