Cette page décrit le format filaire de Tink pour les clés et la sortie primitive. La documentation s'adresse aux cryptographes qui souhaitent ajouter des langues à Tink et aux responsables d'autres bibliothèques de chiffrement de haut niveau qui souhaitent un mode compatible avec le réseau. Il ne s'adresse pas à tous les publics.
Sérialisation des collections de clés
Tink utilise Google protobuf pour sérialiser ses ensembles de clés.
- Une collection de clés sérialisée au format binaire est un proto Keyset sérialisé défini dans tink.proto. La propriété de valeur KeyData d'une clé est un proto sérialisé du type de clé correspondant.
- Un ensemble de clés sérialisé au format JSON est un proto Keyset 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 EncryptedKeyset sérialisé défini dans tink.proto. Il contient une collection de clés sérialisée binaire chiffrée et, éventuellement, des métadonnées KeysetInfo non chiffrées.
Préfixe de sortie Tink
La plupart des primitives Tink sont compatibles avec un préfixe de sortie de 5 octets, qui se compose des éléments suivants :
- Version à 1 octet :
0x01 - Indice de clé de 4 octets : il s'agit de l'ID de la clé utilisée.
Certaines anciennes clés peuvent également être compatibles avec le byte de version 0x00.
Notez que ce préfixe n'est pas authentifié et ne peut pas être utilisé à des fins de sécurité. Tink l'utilise comme indice pour accélérer le déchiffrement ou la validation.
AEAD
En général, Tink met en forme les textes chiffrés AEAD comme suit :
prefix || IV || ciphertext || tag
sauf indication contraire dans la RFC correspondante. prefix est vide ou correspond à un préfixe de sortie Tink de 5 octets.
AES-CTR-HMAC
Pour AES-CTR-HMAC, Tink calcule le MAC avec les données associées (DA) comme suit :
AD || IV || ciphertext || bitlen(AD)
où bitlen(AD) est la longueur de l'AD en bits représentée sous la forme d'un entier non signé de 64 bits big-endian. Ce schéma HMAC suit le brouillon pour AES-CBC-HMAC de Mcgrew.
AEAD déterministe
Tink implémente la RFC 5297 pour AES-SIV, en plaçant le vecteur d'initialisation synthétique (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 n'en accepte qu'une seule, ce qui correspond à une liste avec un seul élément dans la norme RFC 5297. Des données associées vides correspondent à une liste comportant un élément vide, et non à une liste vide.
Streaming AEAD
Consultez AES-CTR HMAC et AES-GCM-HKDF.
Chiffrement encapsulé
Le chiffrement encapsulé chiffre les données avec une clé de chiffrement des données DEK à l'aide des primitives AEAD de Tink. Le chiffrement fonctionne comme suit :
- Un nouveau
DEKest généré à l'aide d'un modèle de clé (ou de paramètres de clé) donné. DEKest sérialisé en chaîne d'octets. Format de sérialisation de la sérialisation du tampon de protocole du proto de type de clé. Par exemple, il s'agit d'un message de tampon de protocoleAesGcmKeysérialisé défini dans aes_gcm.proto pour la clé de chiffrement des données de type AES GCM. Pour savoir comment sérialiser un tampon de protocole, consultez la section Sérialisation de tampon de protocole.- Le
DEKsérialisé est chiffré par un fournisseur externe (GCP, par exemple) dans unencrypted DEK. - Le
DEKest utilisé pour chiffrer le texte brut avec les données associées dansciphertext. Ainsi,ciphertexta exactement le même format que la primitive AEAD correspondant àDEK.
Le format de sortie du chiffrement d'enveloppe est le suivant :
encrypted DEK length || encrypted DEK || ciphertext
encrypted DEK length est un entier big-endian de 32 bits qui stocke la longueur de encrypted DEK (4 octets).
Mac
Tink respecte les RFC correspondantes. Les primitives peuvent ajouter un préfixe de sortie Tink de 5 octets au tag.
Ensemble de PRF
Tink respecte les RFC correspondantes. Notez que pour le 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 du groupe PRF n'ajoutent jamais de préfixe de sortie Tink. Cela garantit que le résultat est bien un PRF.
Chiffrement hybride
Le format général du câble 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 cinq octets. Chaque type de clé contient des informations sur le nombre d'octets à analyser et sur la façon de les analyser à partir de encapsulated_key.
HPKE (chiffrement hybride à clé publique)
Tink suit la norme HPKE définie dans la RFC 9180. Une suite de chiffrement HPKE inclut les trois primitives suivantes.
- Mécanisme d'encapsulation de clé (KEM)
- Fonction de dérivation de clé (KDF)
- Chiffrement authentifié avec données associées (AEAD)
La norme HPKE ne définit pas de format de transfert général dans la section 10 de la RFC 9180. L'implémentation HPKE de Tink utilise les valeurs encapsulated_key et encrypted_data suivantes.
encapsulated_key- Clé publique sérialisée de l'expéditeur
- Défini comme
encdans la section 4.1 de la RFC 9180 - Format déterminé par le KEM HPKE spécifique utilisé
encrypted_data- Texte chiffré et tag (c'est-à-dire
ciphertext || tagsans l'IV) - Défini comme
ctdans la section 4 de la norme RFC 9180 - Format déterminé par l'AEAD HPKE spécifique utilisé
- Texte chiffré et tag (c'est-à-dire
KEM basé sur X25519 Diffie-Hellman
Pour les DHKEM X25519, la valeur enc correspond à la clé 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 de clé (KEM) et encrypted_data est la sortie du mécanisme d'encapsulation de données (DEM).
KEM
Selon le type de clé, Tink utilise des points de courbe elliptique compressés et non compressés, conformément aux normes d'encodage RFC 8422/ANSI.X9-62.2005. Pour les points non compressés, l'octet 0x04 est suivi des coordonnées x et y sous forme d'entiers de taille fixe. Pour les coordonnées compressées, l'octet 0x02 ou 0x03 et la coordonnée x sont utilisés comme un entier de taille fixe. 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 l'AEAD. Cela inclut la spécification d'un vecteur d'initialisation.
Dérivation de clé
La coordonnée X x_ss du point partagé est calculée en premier. La clé de l'AEAD est ensuite définie sur :
HKDF(ikm = encapsulated_key || x_ss, salt = salt_of_key, info = context_info, length = dem_key_size)
où encapsulated_key correspond à la sortie KEM complète en octets.
Signatures numériques
Tink respecte les RFC correspondantes. Les primitives peuvent ajouter un préfixe de sortie Tink de 5 octets au tag généré.
ECDSA
En fonction du champ EcdsaSignatureEncoding dans 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 complétés par des zéros et ont la même taille en octets que l'ordre de la courbe. Par exemple, pour la courbe NIST P-256, r et s sont complétés par des zéros pour atteindre 32 octets.
La signature DER est encodée à l'aide de ASN.1 :
ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }
En particulier, l'encodage est le suivant :
0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s
Tink suit les bonnes pratiques de validation des signatures en n'acceptant que les signatures ECDSA encodées au format DER (les signatures encodées au format BER ne sont pas valides).
Cela permet d'éviter les attaques de malléabilité de signature, qui affectent souvent les systèmes de crypto-monnaie.
Valeurs de préhachage ML-DSA Mu externe
La primitive Prehash transforme un message en valeur prehash, que la primitive SignPrehash signe ensuite. Pour ML-DSA en mode External Mu, comme décrit dans la RFC 9881, la valeur de préhachage est de 69 octets avec la mise en page suivante :
0xff || key_id (4 bytes, big-endian) || mu (64 bytes)
muest la représentation du message ML-DSA, calculée commeSHAKE256(tr || 0x00 || 0x00 || message, 64), oùtrest le hachage de 64 octets de la clé publique, le premier0x00est le séparateur de domaine FIPS 204 pour le ML-DSA pur, et le deuxième0x00est la longueur de la chaîne de contexte (vide). Étant donné quetrest dérivé de la clé publique,muest lié de manière cryptographique à cette clé. Toutefois, la vérification de la liaison nécessite le message d'origine.- Le préfixe de 5 octets est un encadrement Tink, et ne fait pas partie de
mu. Il associe la valeur préhachée à une clé spécifique, afin que SignPrehash sache avec quelle clé signer et puisse rejeter une valeur préhachée pour laquelle il n'a pas de clé. Le préfixe est une métadonnée simple et ne lie rien de manière cryptographique : n'importe qui peut le réécrire.
La signature rejette toute entrée qui ne comporte pas exactement 69 octets, qui ne commence pas par 0xff ou dont l'ID de clé ne correspond pas à une clé activée dans son ensemble de clés.