Beständigkeit

Es ist wichtig, dass Tink sich in allen Programmiersprachen gleich verhält. Dieses Konzept ist nicht geradlinig, aber besonders wichtig:

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

Das Definieren von Konsistenz ist jedoch nicht so einfach, wie man es erwarten würde. Daher stellt diese Seite unsere Arbeitsdefinition dar. Im Grunde bietet Tink zwei Arten von Konsistenz:

  • Bewertungskonsistenz: Wenn die Erstellung des Primitiven in zwei Sprachen für ein bestimmtes Keyset1 erfolgreich ist, verhalten sie sich gleich.
  • Erstellungskonsistenz:Die Erstellung eines Primitives in einer Sprache ist erfolgreich, wenn die Sprache alle Schlüsseltypen in einem Keyset unterstützt. Eine Liste der unterstützten Schlüsseltypen finden Sie hier.

Kontext

Auf übergeordneter Ebene stellt Tink die folgenden APIs bereit:

  • Keyset-Manipulation: Tink bietet APIs zum Hinzufügen neuer Schlüssel zu einem Keyset, zum Entfernen von Schlüsseln aus einem Keyset und zum Ändern des Primärschlüssels in einem Keyset.

  • Keyset-Serialisierung: Tink bietet APIs zum Serialisieren eines Keysets mit einer Byte-Sequenz und zum umgekehrten Parsen eines Keysets aus einer Byte-Sequenz.

  • Einfache Erstellung: Tink bietet eine API zum Erstellen einer Schnittstelle für eine Primitive aus einem Schlüsselsatz. Um beispielsweise ein Aead-Objekt aus einem Keyset in Java zu erstellen, ruft der Nutzer keysetHandle.getPrimitive(Aead.class, config) auf.

  • Einfache Verwendung:Die im einfachen Erstellungsschritt erstellte Schnittstelle bietet eine API zum Ausführen kryptografischer Vorgänge.

Zu diesen APIs müssen zwei wichtige Fragen gestellt werden:

  • Erstellung:Ist es für ein bestimmtes serialisiertes Keyset, eine bestimmte Sprache und ein bestimmtes Primitive möglich, aus diesem Keyset in der Sprache zu erstellen?

  • Evaluierung:Wie verhält sich das primitive Objekt, wenn sich aus einem bestimmten Schlüsselsatz in einer bestimmten Sprache ein Primitive erstellen lässt?

Beachten Sie, dass Tink beim Parsen eines Keysets keine Konsistenz bietet. Zum Beispiel ist es möglich, dass Tink C++

  • parst Keysets mit CHACHA20-POLY1305-Schlüsseln erfolgreich, obwohl CHACHA20-POLY1305 AEAD-Operationen nicht in Tink implementiert sind.
  • parst Keysets erfolgreich mit Schlüsseln, die eine Länge von 1 Byte haben, was in allen kryptografischen Vorgängen fehlschlägt.

Dieses Verhalten kann sich in Nebenversionen ändern.

Konsistenz der Auswertung

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

Im Allgemeinen zielt Tink darauf ab, für Primitive auf offensichtliche Weise einheitlich zu sein. Wenn eine C++-Binärdatei beispielsweise eine Signatur mit public_key_sign->Sign(data) berechnet, wird erwartet, dass der entsprechende Java-Überprüfungsaufruf publicKeyVerify.verify(signature, data) erfolgreich ist.

Allerdings gibt es auch hier einige Einschränkungen. Der Rückgabetyp von aead.Encrypt in Java ist beispielsweise byte[]. Gemäß § 10.7 der Java Language Specification (JLS) ist die Länge eines Arrays vom Typ int, der gemäß §JLS 4.2.1 maximal 2.147.483.647 betragen kann. Daher schlägt die Verschlüsselung eines Arrays mit der Länge 2.147.483.647 in Java fehl. Die Verschlüsselung ist mit einem gewissen Aufwand verbunden, sodass die Ausgabe zu lang wäre. In anderen Sprachen ist jedoch für solche Eingaben eine erfolgreiche Verschlüsselung möglich.

Daher bietet Tink Bewertungskonsistenz: Wenn die Erstellung des Primitiven in einem bestimmten Keyset in zwei Sprachen erfolgreich ist, verhalten sie sich gleich.

Die Ausnahme ist, dass einige Vorgänge unter außergewöhnlichen Umständen fehlschlagen.

Konsistenz bei der Erstellung

Die Erstellung von Primitiven ist nicht immer für alle Schlüsselsätze erfolgreich. In Tink können Nutzer beispielsweise keinen AesSivKey erstellen, wenn das Schlüsselmaterial eine Länge von 128 Bit hat.

Trotzdem sorgt Tink für Konsistenz: Wenn zwei Sprachen beide einen Schlüsseltyp unterstützen, stimmt der Satz von Schlüsseln, für die das Primitive erstellt werden kann, überein. Wenn eine Sprache einen Schlüsseltyp nicht unterstützt, kann natürlich kein primitives Objekt erstellt werden.

Die Konsistenz der Erstellung ist weniger wichtig als die Bewertungskonsistenz und es gibt mehr Ausnahmen von dieser Regel als für die Bewertungskonsistenz. Diese Einschränkungen sind in unserer Liste der unterstützten Schlüsseltypen dokumentiert. Für den Schlüsseltyp ECIES bietet Tink beispielsweise eine Auswahl, welche elliptische Kurve für die Schlüsselvereinbarung verwendet werden soll, aber Java unterstützt X25519 nicht. Daher schlägt die Erstellung eines Schlüssels mit X25519 in Java fehl.

  1. In diesem Dokument wird Keyset in den meisten Sprachen zur Kennzeichnung des Objekts KeysetHandle verwendet. ↩