En esta página, se describe el formato de conexión de Tink para las claves y el resultado básico. El está dirigida a los criptógrafos que quieran agregar lenguajes adicionales Investigadores y encargados de mantenimiento de otras bibliotecas criptográficas de alto nivel modo compatible. No está dirigido al público general.
Serialización de conjunto de claves
Tink usa protobuf de Google para serializar sus conjuntos de claves.
- Un conjunto de claves serializado binario es un protocolo de conjunto de claves serializado definido como tink.proto. La propiedad de valor KeyData de una clave es un modelo proto del tipo de clave correspondiente.
- Un conjunto de claves serializado JSON es un protocolo de conjunto de claves serializado en formato JSON. Ten en cuenta que el valor de KeyData sigue siendo un proto serializado binario.
- Un conjunto de claves encriptado es un proto EncryptedKeyst serializado definido en tink.proto. Contiene un conjunto de claves serializado binario encriptado y, opcionalmente, algunos metadatos de KeysetInfo sin encriptar.
Prefijo de salida de Tink
La mayoría de las primitivas Tink admiten un prefijo de salida de 5 bytes que consta de lo siguiente:
- Versión de 1 byte:
0x01 - Sugerencia de clave de 4 bytes: Este es el ID de la clave que se usó.
Algunas claves heredadas también pueden admitir el byte de versión 0x00.
Ten en cuenta que este prefijo no está autenticado y no se puede confiar en él por razones de seguridad. comerciales. Tink lo usa como pista para acelerar la desencriptación o la verificación.
AEAD
En general, Tink formatea los textos cifrados AEAD de la siguiente manera:
prefix || IV || ciphertext || tag
a menos que se especifique
lo contrario en el RFC correspondiente. prefix está vacío
o un prefijo de salida Tink de 5 bytes.
AES-CTR-HMAC
Para AES-CTR-HMAC, Tink calcula la MAC con los datos asociados (AD) de la siguiente manera:
AD || IV || ciphertext || bitlen(AD)
donde bitlen(AD) es la longitud de AD en bits representados como big-endian de 64 bits.
un número entero sin firma. Este esquema HMAC sigue el borrador para AES-CBC-HMAC de
Mcgrew.
AEAD determinista
Tink implementa RFC 5297 para AES-SIV, lo que coloca la cadena vector de inicialización (SIV) al comienzo del texto cifrado. El primitivo puede agregar un prefijo de salida Tink de 5 bytes.
Aunque RFC 5297 admite una lista de datos asociados, Tink solo admite uno asociado, que corresponde a una lista con un elemento en RFC 5297. Los datos asociados vacíos son una lista con un elemento vacío, y no un elemento vacío. lista.
Transmisión de AEAD
Consulta HMAC de AES-CTR y AES-GCM-HKDF.
Encriptación de sobre
La encriptación de sobre encripta los datos con una clave de encriptación de datos DEK mediante
Primitivas de AEAD de Tink La encriptación funciona de la siguiente manera:
- Se genera un
DEKnuevo con una plantilla de claves determinada (o parámetros de clave). DEKse serializa en una string de bytes. El formato de serialización serialización de búfer de protocolo del tipo de clave proto. Por ejemplo, esta es una mensaje de búfer de protocoloAesGcmKeyserializado definido en aes_gcm.proto para la DEK de tipo de clave AES GCM. Consulta Serialización de búfer de protocolo para saber cómo serializar un búfer de protocolo.- El
DEKserializado está encriptado por un proveedor externo (por ejemplo, GCP). en unencrypted DEK. DEKse usa para encriptar el texto simple con los datos asociados enciphertextPor lo tanto,ciphertexttiene exactamente el mismo formato que la primitiva AEAD. que corresponde alDEK.
El formato de salida de la encriptación de sobre es el siguiente:
encrypted DEK length || encrypted DEK || ciphertext
encrypted DEK length es de 4 bytes, que almacena la longitud de encrypted DEK
como un entero big-endian de 32 bits.
MAC
Tink sigue las RFC correspondientes. Los valores primitivos pueden agregar un resultado de Tink de 5 bytes prefijo de la etiqueta.
Se estableció PRF
Tink sigue las RFC correspondientes. Ten en cuenta que, para PRF Set, el tipo de clave es diferente. a partir del tipo de clave MAC del mismo algoritmo, sin incluir la longitud de salida. Las claves Set de PRF nunca agregan un prefijo de salida Tink. Esto garantiza que la salida sea realmente un PRF.
Encriptación híbrida
El formato de conexión general para la encriptación híbrida Tink es el siguiente:
prefix || encapsulated_key || encrypted_data
prefix está vacío o es un prefijo de salida Tink de 5 bytes. Cada tipo de clave contiene
información sobre cuántos bytes analizar y cómo analizarlos desde
encapsulated_key
HPKE (encriptación de clave pública híbrida)
Tink sigue el estándar HPKE definido en RFC 9180. Un conjunto de algoritmos de cifrado HPKE incluye las siguientes tres primitivas.
- Mecanismo de encapsulamiento de claves (KEM)
- Función de derivación de claves (KDF)
- Encriptación autenticada con datos asociados (AEAD)
El estándar HPKE no define un formato de conexión general en la sección RFC 9180,
10. La implementación de HPKE de Tink utiliza lo siguiente
Valores encapsulated_key y encrypted_data.
encapsulated_key- Clave pública serializada del remitente
- Se definió como
encen RFC 9180, sección 4.1 - Formato determinado por la HPKE KEM específica utilizada
encrypted_data- Texto de cifrado y etiqueta (es decir,
ciphertext || tagsin el IV) - Se definió como
cten RFC 9180, sección 4 - Formato determinado por la HPKE AEAD específica utilizada
- Texto de cifrado y etiqueta (es decir,
X25519 KEM con sede en Diffie-Hellman
Para los DHKEM de X25519, el valor enc es el valor público Diffie-Hellman de 32 bytes del remitente.
.
ECIES-AEAD-HKDF
Para la implementación ECIES-AEAD-HKDF de Tink, encapsulated_key es el resultado
del mecanismo de encapsulamiento de claves (KEM) y encrypted_data es la salida
del mecanismo de encapsulamiento de datos (DEM).
KEM
Según el tipo de clave, Tink usa una curva elíptica comprimida y no comprimida.
de acuerdo con los estándares de codificación RFC 8422/ANSI.X9-62.2005. Para
puntos sin comprimir, al byte 0x04 le siguen x y y
como números enteros de tamaño fijo. Para las coordenadas comprimidas, el byte 0x02
o 0x03 y la coordenada x como un número entero de tamaño fijo. Para X25519,
se usa la definición RFC 7748 (coordenada x como número entero de tamaño fijo).
DEM
Para encrypted_data, Tink usa el mismo formato que AEAD. Esto incluye
especificar un IV.
Derivación de claves
Primero, se calcula la coordenada X x_ss del punto compartido. La clave para el
AEAD se establece en:
HKDF(ikm = encapsulated_key || x_ss, salt = salt_of_key, info = context_info, length = dem_key_size)
donde encapsulated_key es la salida completa de KEM en forma de bytes.
Firmas digitales
Tink sigue las RFC correspondientes. Los valores primitivos pueden agregar un resultado de Tink de 5 bytes a la etiqueta que se genera.
ECDSA
Según el campo EcdsaSignatureEncoding de la clave,
el formato de una firma ECDSA es IEEE P1363 o ASN.1 DER.
El formato de la firma IEEE P1363 es r || s, en el que r y s son
y tienen el mismo tamaño en bytes que el orden de la curva. Para
Por ejemplo, para la curva NIST P-256, r y s tienen 32 bytes con padding cero.
La firma DER se codifica con ASN.1:
ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }
En particular, la codificación es la siguiente:
0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s
Tink sigue las prácticas recomendadas para la verificación de firmas, ya que solo acepta Firmas ECDSA con codificación DER (las firmas alternativas codificadas BER no son válidas)
Esto ayuda a prevenir ataques de maleabilidad a la firma, que a menudo afectan de criptomonedas.