Konsistenz

Es ist wichtig, dass sich Tink in allen Programmiersprachen „gleich“ verhält. Dieses Konzept ist nicht einfach, aber vor allem:

Um die Konsistenz zu wahren, verwendet Tink sprachübergreifende Tests, die im sprachübergreifenden GitHub-Repository zu finden sind. Mit diesen Tests werden die Konsistenz und Interoperabilität verschiedener Sprachen überprüft.

Die Definition von Konsistenz ist jedoch nicht so einfach, wie man erwarten würde. Daher finden Sie auf dieser Seite unsere Arbeitsdefinition. Grundsätzlich bietet Tink zwei Arten von Konsistenz:

Kontext

Auf übergeordneter Ebene bietet Tink die folgenden APIs:

  • Schlüsselsatzmanipulation: Tink bietet APIs, mit denen Sie einem Schlüsselsatz neue Schlüssel hinzufügen, Schlüssel aus einem Schlüsselsatz entfernen und den Primärschlüssel in einem Schlüsselsatz ändern können.

  • Schlüsselsatz-Serialisierung: Tink bietet APIs, um einen Schlüsselsatz in eine Bytefolge zu serialisieren und umgekehrt einen Schlüsselsatz aus einer Bytefolge zu parsen.

  • Primitive erstellen: Tink bietet eine API, mit der eine Schnittstelle für ein Primitiv aus einem Schlüsselsatz erstellt werden kann. Wenn Sie beispielsweise ein Aead-Objekt aus einem Schlüsselsatz in Java erstellen möchten, rufen Sie keysetHandle.getPrimitive(config, Aead.class) auf.

  • Primitive Verwendung: Die im Schritt zur Erstellung des Primitivs erzeugte Schnittstelle bietet eine API zum Ausführen kryptografischer Vorgänge.

Zu diesen APIs gibt es zwei wichtige Fragen:

  • Erstellung: Ist es für einen bestimmten serialisierten Schlüsselsatz, eine bestimmte Sprache und ein bestimmtes Primitiv möglich, das Primitiv aus diesem Schlüsselsatz in der Sprache zu erstellen?

  • Auswertung: Wenn ein Primitive in einer Sprache aus einem bestimmten Keyset erstellt werden kann, wie verhält sich das Primitive-Objekt?

Beachten Sie, dass Tink beim Parsen eines Schlüsselsatzes keine Konsistenz bietet. Es ist beispielsweise möglich, dass Tink C++

  • Schlüsselsätze mit CHACHA20-POLY1305-Schlüsseln werden erfolgreich geparst, obwohl CHACHA20-POLY1305-AEAD-Vorgänge nicht in Tink implementiert sind.
  • Keysets mit Schlüsseln mit einer Länge von 1 Byte werden erfolgreich geparst, schlagen jedoch bei allen kryptografischen Vorgängen fehl.

Diese Verhaltensweisen können sich in Nebenversionen ändern.

Konsistenz der Bewertung

Die Konsistenz der Auswertung ist wichtiger als die Konsistenz im Erstellungsprozess: Wenn eine AEAD in Java die Verschlüsselung der AEAD in C++ nicht entschlüsseln kann, haben Nutzer ein ernsthaftes Problem.

Im Allgemeinen ist Tink bestrebt, bei Primitiven auf offensichtliche Weise konsistent zu sein. Wenn beispielsweise eine C++-Binärdatei eine Signatur mit public_key_sign->Sign(data) berechnet, sollte der entsprechende Java-Bestätigungsaufruf publicKeyVerify.verify(signature, data) erfolgreich sein.

Aber auch hier gibt es einige Einschränkungen. Der Rückgabetyp von aead.Encrypt in Java ist beispielsweise ein byte[]. Gemäß der Java Language Specification (JLS) §10.7 ist die Länge eines Arrays vom Typ int, der gemäß §JLS 4.2.1 maximal 2147483647 betragen kann. Daher schlägt die Verschlüsselung eines Arrays mit einer Länge von 2147483647 in Java fehl: Die Verschlüsselung hat einen gewissen Overhead, was bedeutet, dass die Ausgabe zu lang wäre. In anderen Sprachen ist die Verschlüsselung für solche Eingaben jedoch zulässig.

Daher bietet Tink eine konsistente Auswertung: Wenn die Erstellung des Primitivs für einen bestimmten Schlüsselsatz in zwei Sprachen erfolgreich ist, verhalten sie sich gleich.

Die Ausnahme ist, dass einige Vorgänge unter bestimmten Umständen fehlschlagen können.

Regelmäßige Erstellung

Die Erstellung von Primitiven ist nicht immer für alle Schlüsselsätze erfolgreich. Tink lässt beispielsweise nicht zu, dass Nutzer einen AesSivKey erstellen, wenn das Schlüsselmaterial eine Länge von 128 Bit hat.

Tink bietet jedoch die folgende Konsistenz: Wenn zwei Sprachen einen Schlüsseltyp unterstützen, ist der Satz von Schlüsseln, für die das Primitive erstellt werden kann, identisch. Wenn eine Sprache einen Schlüsseltyp nicht unterstützt, kann natürlich kein primitives Objekt erstellt werden.

Die Konsistenz bei der Erstellung ist weniger wichtig als die Konsistenz bei der Bewertung. Außerdem gibt es mehr Ausnahmen von dieser Regel als bei der Konsistenz bei der Bewertung. Diese Einschränkungen sind in der Liste der unterstützten Schlüsseltypen dokumentiert. Für den Schlüsseltyp ECIES bietet Tink beispielsweise eine Auswahl an elliptischen Kurven für die Schlüsselvereinbarung, Java unterstützt jedoch X25519 nicht. Daher schlägt die Erstellung eines Schlüssels mit X25519 in Java fehl.

  1. In diesem Dokument verwenden wir den Begriff Keyset für das Objekt, das in den meisten Sprachen KeysetHandle genannt wird. ↩