Tink Wire-Format

Auf dieser Seite wird das Sendeformat von Tink für Schlüssel und primitive Ausgabe beschrieben. Die ist für Kryptografen gedacht, die Tink und Administratoren anderer Kryptobibliotheken, die eine Überweisung wünschen kompatiblen Modus. Sie ist nicht für alle Altersgruppen vorgesehen.

Schlüsselsatz-Serialisierung

Tink verwendet Google protobuf, um seine Keysets zu serialisieren.

  • Ein binäres serialisiertes Keyset ist ein serialisiertes Keyset-Protokoll, das in tink.proto. Das Wertattribut „KeyData“ eines Schlüssels ist ein serialisierter Proto-Datei des entsprechenden Schlüsseltyps.
  • Ein JSON-serialisiertes Schlüsselsatz ist ein Schlüsselsatzproto, das im JSON-Format serialisiert ist. Beachten Sie, dass der KeyData-Wert immer noch ein binär serialisiertes Proto ist.
  • Ein verschlüsselter Schlüsselsatz ist ein serialisierter EncryptedKeyst-Proto, der in tink.proto. Sie enthält einen verschlüsselten binären serialisierten Schlüsselsatz. und optional einige unverschlüsselte KeysetInfo-Metadaten.

Tink-Ausgabepräfix

Die meisten Tink-Primitive unterstützen ein 5-Byte-Ausgabepräfix, das aus Folgendem besteht:

  • 1-Byte-Version: 0x01
  • 4-Byte-Schlüsselhinweis: Dies ist die Schlüssel-ID des verwendeten Schlüssels.

Einige alte Schlüssel unterstützen möglicherweise auch das Versionsbyte 0x00.

Dieses Präfix ist nicht authentifiziert und kann nicht für die Sicherheit verwendet werden zu verstehen. Tink verwendet sie als Hinweis, um die Entschlüsselung oder Überprüfung zu beschleunigen.

AEAD

Im Allgemeinen formatiert Tink AEAD-Geheimtexte so:

prefix || IV || ciphertext || tag

sofern im entsprechenden RFC nicht anders angegeben. prefix ist entweder leer oder ein 5-Byte-Tink-Ausgabepräfix.

AES-CTR-HMAC

Für AES-CTR-HMAC berechnet Tink den MAC mit verknüpften Daten (AD) wie folgt:

AD || IV || ciphertext || bitlen(AD)

wobei bitlen(AD) die Länge von AD in Bit ist, dargestellt als 64-Bit-Big-Endian Vorzeichenlose Ganzzahl. Dieses HMAC-Schema folgt dem Entwurf für AES-CBC-HMAC von Mcgrew.

Deterministischer AEAD

Tink implementiert RFC 5297 für AES-SIV, wodurch die synthetische Initialisierungsvektor (SIV) am Anfang des Geheimtexts. Das Primitiv kann ein 5-Byte-Tink-Ausgabepräfix hinzufügen.

Während RFC 5297 eine Liste verknüpfter Daten unterstützt, unterstützt Tink nur genau Eine verknüpfte Daten, die einer Liste mit einem Element in RFC 5297 entspricht. Leere verknüpfte Daten sind Listen mit einem leeren Element. Liste.

Streaming von AEAD

Siehe AES-CTR HMAC und AES-GCM-HKDF:

Umschlagverschlüsselung

Bei der Umschlagverschlüsselung werden die Daten mit einem Datenverschlüsselungsschlüssel DEK verschlüsselt: Die AEAD-Primitive von Tink. Die Verschlüsselung funktioniert so:

  • Mithilfe einer bestimmten Schlüsselvorlage (oder Schlüsselparametern) wird eine neue DEK generiert.
  • DEK wird in einen Bytestring serialisiert. Das Serialisierungsformat der Protokollpufferserialisierung des Schlüsseltyps proto. Dies ist zum Beispiel ein serialisierte AesGcmKey-Protokollpuffernachricht, definiert in aes_gcm.proto für DEK des Schlüsseltyps AES GCM. Informationen zur Serialisierung finden Sie unter Protokollzwischenspeicher-Serialisierung. Protokollpuffer.
  • Die serialisierte DEK wird von einem externen Anbieter (z. B. GCP) verschlüsselt. in encrypted DEK umwandeln.
  • Die DEK wird verwendet, um den Klartext mit den zugehörigen Daten zu verschlüsseln. ciphertext. ciphertext hat also genau dasselbe Format wie das AEAD-Primitive die dem DEK entsprechen.

Das Ausgabeformat der Umschlagverschlüsselung lautet wie folgt:

encrypted DEK length || encrypted DEK || ciphertext

encrypted DEK length beträgt 4 Byte und speichert die Länge von encrypted DEK als 32-Bit-Big-Endian-Ganzzahl.

MAC

Tink folgt den entsprechenden RFCs. Primitives können eine 5-Byte-Tink-Ausgabe hinzufügen -Präfix hinzufügen.

PRF festgelegt

Tink folgt den entsprechenden RFCs. Beachten Sie, dass sich der Schlüsseltyp für das PRF-Set unterscheidet. aus dem MAC-Schlüsseltyp desselben Algorithmus heraus, indem die Ausgabelänge nicht angegeben wird. PRF-Set-Schlüssel fügen niemals ein Tink-Ausgabepräfix hinzu. So wird sichergestellt, dass die Ausgabe ein PRF.

Hybridverschlüsselung

Das allgemeine Übertragungsformat für die Tink-Hybridverschlüsselung ist das folgende:

prefix || encapsulated_key || encrypted_data

prefix ist entweder leer oder ein 5-Byte-Tink-Ausgabepräfix. Jeder Schlüsseltyp enthält wie viele Bytes geparst werden und wie diese Bytes geparst werden. encapsulated_key

HPKE (Hybrid-Public-Key-Verschlüsselung)

Tink entspricht dem in RFC 9180 definierten HPKE-Standard. Eine HPKE-Cipher Suite umfasst die folgenden drei Primitive.

  • Key Kapselungsmechanismus (KEM)
  • Schlüsselableitungsfunktion (KDF)
  • Authentifizierte Verschlüsselung mit verknüpften Daten (Authenticated Encryption with Associated Data, AEAD)

Der HPKE-Standard definiert kein allgemeines Übertragungsformat in RFC 9180, Abschnitt 10. Für die HPKE-Implementierung von Tink wird Folgendes verwendet: encapsulated_key- und encrypted_data-Werte.

  • encapsulated_key
    • Serialisierter öffentlicher Schlüssel des Senders
    • Definiert als enc in RFC 9180, Abschnitt 4.1
    • Format, das durch das verwendete spezifische HPKE KEM bestimmt wird
  • encrypted_data
    • Geheimtext und Tag (z.B. ciphertext || tag ohne IV)
    • Definiert als ct in RFC 9180, Abschnitt 4
    • Format, das durch das verwendete spezifische HPKE AEAD bestimmt wird
X25519 – KEM aus Diffie-Hellman

Bei X25519-DHKEMs ist der Wert enc das öffentliche 32-Byte-Diffie-Hellman-Element des Absenders .

ECIES-AEAD-HKDF

Für die ECIES-AEAD-HKDF-Implementierung von Tink ist encapsulated_key die Ausgabe des Key Encapsulation Mechanism (KEM) und encrypted_data ist die Ausgabe des Data Encapsulation Mechanism (DEM) vorgestellt.

KEM

Je nach Schlüsseltyp verwendet Tink komprimierte und unkomprimierte elliptische Kurven gemäß RFC 8422/ANSI.X9-62.2005-Codierungsstandards. Für unkomprimierten Punkten, folgen auf das Byte 0x04 die x und die y. -Koordinaten als Ganzzahlen fester Größe. Bei komprimierten Koordinaten hat das Byte 0x02 oder 0x03 und die x-Koordinate als Ganzzahl mit fester Größe wird verwendet. Für X25519, Es wird die Definition von RFC 7748 verwendet (x-Koordinate als Ganzzahl mit fester Größe).

DEM

Für encrypted_data verwendet Tink dasselbe Format wie der AEAD. Dazu gehören und eine IV.

Schlüsselableitung

Zuerst wird die X-Koordinate x_ss des gemeinsamen Punkts berechnet. Der Schlüssel für die AEAD wird dann eingestellt auf:

HKDF(ikm = encapsulated_key || x_ss, salt = salt_of_key, info = context_info, length = dem_key_size)

Dabei ist encapsulated_key die vollständige KEM-Ausgabe in Byte.

Digitale Signaturen

Tink folgt den entsprechenden RFCs. Primitives können eine 5-Byte-Tink-Ausgabe hinzufügen vor dem generierten Tag ein.

ECDSA

Je nach EcdsaSignatureEncoding im Schlüssel Das Format einer ECDSA-Signatur ist entweder IEEE P1363 oder ASN.1 DER.

Das Format der IEEE P1363-Signatur ist r || s, wobei r und s mit null aufgefüllt sind und dieselbe Größe in Byte haben wie die Reihenfolge der Kurve. Für Für die NIST P-256-Kurve werden r und s beispielsweise auf 32 Byte aufgefüllt.

Die DER-Signatur wird mit ASN.1 codiert:

ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }

Die Codierung lautet insbesondere:

0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s

Tink befolgt die Best Practices für die Signaturprüfung, indem es DER-codierte ECDSA-Signaturen (alternative BER-codierte Signaturen sind ungültig).

Dies trägt dazu bei, Angriffe auf die charakteristische Formbarkeit zu verhindern, die häufig Kryptowährungssysteme.