Esta página descreve o formato de transmissão da Tink para chaves e saídas primitivas. A documentação é destinada a criptógrafos que querem adicionar outros idiomas ao Tink e a mantenedores de outras bibliotecas criptográficas de alto nível que querem um modo compatível com a rede. Ele não é destinado ao público em geral.
Serialização do conjunto de chaves
O Tink usa o Google protobuf para serializar os conjuntos de chaves.
- Um conjunto de chaves serializado binário é um proto de conjunto de chaves serializado definido em tink.proto. A propriedade de valor KeyData de uma chave é um protótipo serializado do tipo de chave correspondente.
- Um conjunto de chaves serializado em JSON é um proto de conjunto de chaves serializado no formato JSON. O valor de KeyData ainda é um proto serializado binário.
- Um conjunto de chaves criptografadas é um proto EncryptedKeyset serializado definido em tink.proto. Ele contém um conjunto de chaves serializado binário criptografado e, opcionalmente, alguns metadados KeysetInfo não criptografados.
Prefixo de saída do Tink
A maioria das primitivas do Tink oferece suporte a um prefixo de saída de 5 bytes composto por:
- Versão de 1 byte:
0x01 - Sugestão de chave de 4 bytes: é o ID da chave usada.
Algumas chaves legados também podem oferecer suporte ao byte de versão 0x00.
Esse prefixo não é autenticado e não pode ser usado para fins de segurança. O Tink usa isso como uma dica para acelerar a descriptografia ou verificação.
AEAD
Em geral, o Tink formata textos criptografados AEAD da seguinte maneira:
prefix || IV || ciphertext || tag
a menos que especificado de outra forma no RFC correspondente. prefix está vazio
ou é um prefixo de saída do Tink de 5 bytes.
AES-CTR-HMAC
Para AES-CTR-HMAC, o Tink calcula o MAC com dados associados (AD) da seguinte maneira:
AD || IV || ciphertext || bitlen(AD)
em que bitlen(AD) é o comprimento de AD em bits representado como número inteiro não assinado
big-endian de 64 bits. Esse esquema HMAC segue o draft para AES-CBC-HMAC de
Mcgrew (link em inglês).
AEAD determinista
O Tink implementa o RFC 5297 para AES-SIV, colocando o vetor de inicialização sintética (SIV) no início do texto criptografado. A primitiva pode adicionar um prefixo de saída do Tink de 5 bytes.
Enquanto o RFC 5297 oferece suporte a uma lista de dados associados, o Tink oferece suporte apenas a um único dado associado, que corresponde a uma lista com um elemento no RFC 5297. Os dados associados vazios são uma lista com um elemento vazio, e não uma lista vazia.
AEAD de streaming
Consulte HMAC AES-CTR e AES-GCM-HKDF.
Criptografia de envelope
A criptografia de envelope criptografa os dados com uma chave de criptografia de dados DEK usando
as primitivas AEAD do Tink. A criptografia funciona da seguinte maneira:
- Uma nova
DEKé gerada usando um determinado modelo de chave (ou parâmetros de chave). - O
DEKé serializado em uma string de bytes. O formato de serialização da serialização do buffer de protocolo do proto do tipo de chave. Por exemplo, esta é uma mensagem de buffer de protocoloAesGcmKeyserializada definida em aes_gcm.proto para DEK do tipo de chave AES GCM. Consulte Serialização de buffer de protocolo para saber como serializar um buffer de protocolo. - O
DEKserializado é criptografado por um provedor externo (por exemplo, o GCP) em umencrypted DEK. - O
DEKé usado para criptografar o texto simples com os dados associados emciphertext. Portanto,ciphertexttem o mesmo formato da primitiva AEAD correspondente aDEK.
O formato de saída da criptografia de envelope é o seguinte:
encrypted DEK length || encrypted DEK || ciphertext
O encrypted DEK length tem 4 bytes, armazenando o comprimento do encrypted DEK
como um número inteiro big-endian de 32 bits.
MAC
O Tink segue os RFCs correspondentes. Os primitivos podem adicionar um prefixo de saída Tink de 5 bytes à tag.
Conjunto de PRF
O Tink segue os RFCs correspondentes. Observe que, para o conjunto de PRF, o tipo de chave é diferente do tipo de chave MAC do mesmo algoritmo, não incluindo a duração da saída. As chaves de conjunto de PRF nunca adicionam um prefixo de saída do Tink. Isso garante que a saída seja realmente um PRF.
Criptografia híbrida
O formato de transmissão geral para a criptografia híbrida do Tink é o seguinte:
prefix || encapsulated_key || encrypted_data
prefix está vazio ou é um prefixo de saída do Tink de 5 bytes. Cada tipo de chave contém
informações sobre quantos bytes analisar e como analisar esses bytes de
encapsulated_key.
HPKE (criptografia de chave pública híbrida)
O Tink segue o padrão HPKE definido na RFC 9180. Um conjunto de cifras HPKE inclui as três primitivas a seguir.
- Mecanismo de encapsulamento de chaves (KEM)
- Função de derivação de chaves (KDF)
- Criptografia autenticada com dados associados (AEAD)
O padrão HPKE não define um formato de transmissão geral na RFC 9180, seção
10. A implementação do HPKE do Tink usa os seguintes
valores de encapsulated_key e encrypted_data.
encapsulated_key- Chave pública serializada do remetente
- Definido como
encna RFC 9180, seção 4.1. - Formato determinado pelo KEM do HPKE usado
encrypted_data- Texto criptografado e tag (por exemplo,
ciphertext || tagsem o IV) - Definido como
ctna RFC 9180, seção 4. - Formato determinado pelo AEAD específico do HPKE usado
- Texto criptografado e tag (por exemplo,
KEM baseado em Diffie-Hellman X25519
Para DHKEMs X25519, o valor enc é a chave pública Diffie-Hellman de 32 bytes do
remetente.
ECIES-AEAD-HKDF
Na implementação do ECIES-AEAD-HKDF do Tink, encapsulated_key é a saída
do mecanismo de encapsulamento de chaves (KEM, na sigla em inglês) e encrypted_data é a saída
do mecanismo de encapsulamento de dados (DEM, na sigla em inglês).
KEM
Dependendo do tipo de chave, o Tink usa pontos de curva elíptica compactados e não compactados, seguindo os padrões de codificação RFC 8422/ANSI.X9-62.2005. Para
pontos descomprimidos, o byte 0x04 é seguido por x e a coordenada y
como números inteiros de tamanho fixo. Para coordenadas compactadas, o byte 0x02
ou 0x03 e a coordenada x como um número inteiro de tamanho fixo são usados. Para X25519,
a definição da RFC 7748 é usada (coordenada x como número inteiro de tamanho fixo).
DEM
Para encrypted_data, o Tink usa o mesmo formato do AEAD. Isso inclui
especificar uma IV.
Derivação de chaves
Primeiro, a coordenada x x_ss do ponto compartilhado é calculada. A chave do
AEAD é definida como:
HKDF(ikm = encapsulated_key || x_ss, salt = salt_of_key, info = context_info, length = dem_key_size)
em que encapsulated_key é a saída completa do KEM em bytes.
Assinaturas digitais
O Tink segue os RFCs correspondentes. Os primitivos podem adicionar um prefixo de saída de 5 bytes da Tink à tag gerada.
ECDSA
Dependendo do campo EcdsaSignatureEncoding na chave,
o formato de uma assinatura ECDSA é IEEE P1363 ou ASN.1 DER.
O formato da assinatura IEEE P1363 é r || s, em que r e s são
preenchidos com zeros e têm o mesmo tamanho em bytes que a ordem da curva. Por
exemplo, para a curva NIST P-256, r e s são preenchidos com zeros até 32 bytes.
A assinatura DER é codificada usando ASN.1:
ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }
Especificamente, a codificação é:
0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s
O Tink segue as práticas recomendadas para verificação de assinatura, aceitando apenas assinaturas ECDSA codificadas em DER. Assinaturas codificadas em BER alternativas são inválidas.
Isso ajuda a evitar ataques de modificação de assinatura, que muitas vezes afetam sistemas de criptomoedas.