Format de fil Tink

Cette page décrit le format filaire de Tink pour les clés et la sortie primitive. La s’adresse aux cryptographes qui souhaitent ajouter des langues Diriger et gérer d'autres bibliothèques de cryptographie de haut niveau qui veulent un virement mode compatible. Elle n'est pas destinée à tous les publics.

Sérialisation de collections de clés

Tink utilise le protobuf Google pour sérialiser ses collections de clés.

  • Une collection de clés sérialisée binaire est un proto de collection de clés sérialisé défini dans tink.proto. La propriété de valeur KeyData d'une clé correspond à un type de données proto du type de clé correspondant.
  • Une collection de clés sérialisée JSON est un fichier proto de collection de clés sérialisé au format JSON. Notez que la valeur KeyData est toujours un proto sérialisé binaire.
  • Une collection de clés chiffrée est un proto EncryptedKeyst sérialisé défini dans tink.proto. Il contient une collection de clés sérialisées et binaires chiffrées. et éventuellement des métadonnées KeysetInfo non chiffrées.

Préfixe de sortie Tink

La plupart des primitives Tink acceptent un préfixe de sortie de 5 octets composé des éléments suivants:

  • Version à 1 octet: 0x01
  • Indice de clé (4 octets) : ID de la clé utilisée.

Certaines anciennes clés peuvent également accepter l'octet de version 0x00.

Notez que ce préfixe n'est pas authentifié et ne peut pas être utilisé pour des raisons de sécurité objectifs. Tink s'en sert comme indice pour accélérer le déchiffrement ou la validation.

AEAD

En général, Tink formate les textes chiffrés AEAD comme suit:

prefix || IV || ciphertext || tag

sauf indication contraire dans le document RFC correspondant. prefix est vide ou un préfixe de sortie Tink de 5 octets.

AES-CTR-HMAC

Pour AES-CTR-HMAC, Tink calcule l'adresse MAC avec les données associées (AD) comme suit:

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

où bitlen(AD) est la longueur d'AD en bits représentée par une version big-endian de 64 bits entier non signé. Ce schéma HMAC suit le projet AES-CBC-HMAC de Mcgrew.

AEAD déterministe

Tink met en œuvre la norme RFC 5297 pour AES-SIV, mettant ainsi le code du vecteur d'initialisation (SIV) au début du texte chiffré. La primitive peut ajouter un préfixe de sortie Tink de 5 octets.

Alors que la norme RFC 5297 accepte une liste de données associées, Tink ne prend en charge que une donnée associée, qui correspond à une liste avec un élément dans RFC 5297. Une donnée associée vide est une liste comportant un élément vide, et non une liste vide liste.

AEAD de streaming

Voir AES-CTR HMAC et AES-GCM-HKDF :

Chiffrement encapsulé

Le chiffrement encapsulé chiffre les données à l'aide d'une clé de chiffrement de données DEK à l'aide de Les primitives AEAD de Tink. Le chiffrement fonctionne comme suit:

  • Un nouveau DEK est généré à l'aide d'un modèle de clé (ou de paramètres de clé) donnés.
  • Le DEK est sérialisé dans une chaîne d'octets. Le format de sérialisation Sérialisation du tampon de protocole du type de clé proto. Par exemple, il s'agit d'un message de tampon de protocole AesGcmKey sérialisé défini dans aes_gcm.proto pour la clé DEK de type AES GCM Consultez la section Sérialisation du tampon de protocole pour savoir comment sérialiser un tampon de protocole.
  • Le fichier DEK sérialisé est chiffré par un fournisseur externe (par exemple, GCP). en encrypted DEK.
  • DEK permet de chiffrer le texte brut avec les données associées dans ciphertext ciphertext a donc exactement le même format que la primitive AEAD. correspondant au DEK.

Le format de sortie du chiffrement encapsulé est le suivant:

encrypted DEK length || encrypted DEK || ciphertext

encrypted DEK length est de 4 octets et stocke la longueur du encrypted DEK. en tant qu'entier big-endian de 32 bits.

Mac

Tink suit les RFC correspondantes. Les primitives peuvent ajouter une sortie Tink de 5 octets au tag.

PRF défini

Tink suit les RFC correspondantes. Notez que pour l'ensemble PRF, le type de clé diffère du type de clé MAC du même algorithme en n’incluant pas la longueur de sortie. Les clés PRF Set n'ajoutent jamais de préfixe de sortie Tink. Cela garantit que le résultat est réellement un formulaire de demande de subvention.

Chiffrement hybride

Le format filaire général pour le chiffrement hybride Tink est le suivant:

prefix || encapsulated_key || encrypted_data

prefix est vide ou correspond à un préfixe de sortie Tink de 5 octets. Chaque type de clé contient les informations sur le nombre d'octets à analyser et la façon d'analyser ces octets à partir encapsulated_key

HPKE (Chiffrement de clé publique hybride)

Tink respecte la norme HPKE définie dans le document RFC 9180. Une suite de chiffrement HPKE comprend les trois primitives suivantes.

  • Mécanisme d'encapsulation de clé (KEM)
  • Fonction de dérivation de clé (KDF)
  • Chiffrement authentifié avec les données associées (AEAD)

La norme HPKE ne définit pas de format filaire général dans la section RFC 9180 10. L'implémentation HPKE de Tink utilise les éléments suivants : Valeurs encapsulated_key et encrypted_data.

  • encapsulated_key
    • Clé publique sérialisée de l'expéditeur
    • Défini en tant que enc dans RFC 9180, section 4.1
    • Format déterminé par le HPKE KEM spécifique utilisé
  • encrypted_data
    • Texte chiffré et tag (par exemple, ciphertext || tag sans vecteur d'initialisation)
    • Défini en tant que ct dans RFC 9180, section 4
    • Format déterminé par le HPKE AEAD spécifique utilisé
Solution KEM basée sur Diffie-Hellman X25519

Pour les DHKEM X25519, la valeur enc correspond à la plage publique Diffie-Hellman de 32 octets de l'expéditeur. .

ECIES-AEAD-HKDF

Pour l'implémentation ECIES-AEAD-HKDF de Tink, encapsulated_key est la sortie. du mécanisme d'encapsulation des clés (KEM), et encrypted_data est la sortie du mécanisme d'encapsulation des données (DEM).

KEM

Selon le type de clé, Tink utilise une courbe elliptique compressée et non compressée selon les normes d'encodage RFC 8422/ANSI.X9-62.2005. Pour points non compressés, l'octet 0x04 est suivi de x et de y sous forme d'entiers de taille fixe. Pour les coordonnées compressées, l'octet 0x02 ou 0x03, et la coordonnée x sous forme de nombre entier de taille fixe est utilisée. Pour X25519, la définition RFC 7748 est utilisée (coordonnée x en tant qu'entier de taille fixe).

DEM

Pour encrypted_data, Tink utilise le même format que le fichier AEAD. Cela inclut spécifiant un vecteur d'initialisation.

Dérivation de clé

La coordonnée X (x_ss) du point partagé est d'abord calculée. La clé de la section AEAD est ensuite défini sur:

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

où encapsulated_key est la sortie complète KEM en octets.

Signatures numériques

Tink suit les RFC correspondantes. Les primitives peuvent ajouter une sortie Tink de 5 octets au tag généré.

ECDSA

En fonction du champ EcdsaSignatureEncoding de la clé, le format d'une signature ECDSA est IEEE P1363 ou ASN.1 DER.

Le format de la signature IEEE P1363 est r || s, où r et s sont remplis de zéro et ont la même taille en octets que l’ordre de la courbe. Pour Par exemple, pour la courbe NIST P-256, r et s sont complétés par zéro jusqu'à 32 octets.

La signature DER est encodée à l'aide de ASN.1:

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

Voici son encodage:

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

Tink respecte les bonnes pratiques de validation de signature en n'acceptant Signatures ECDSA encodées au format DER (les autres signatures encodées en BERT ne sont pas valides).

Cela permet d'éviter les attaques de maléabilité, qui affectent souvent les systèmes de cryptomonnaies.