Nesta página, descrevemos o formato de transmissão do Tink para chaves e saída primitiva. A a documentação é voltada a criptógrafos que desejam adicionar outras linguagens aos Tink e mantenedores de outras bibliotecas de criptografia de alto nível que querem uma conexão modo compatível. Ele não é destinado ao público geral.
Serialização do conjunto de chaves
O Tink usa o protobuf do Google 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 valor proto do tipo de chave correspondente.
- Um conjunto de chaves serializado em JSON é um proto de conjunto de chaves serializado no formato JSON. Observe que o valor de KeyData ainda é um proto serializado binário.
- Um conjunto de chaves criptografado é um proto EncryptedKeyst serializado definido em tink.proto. 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 dos primitivos do Tink é compatível com um prefixo de saída de 5 bytes que consiste em:
- Versão de 1 byte:
0x01 - Dica de chave de 4 bytes: esse é o ID da chave usada.
Algumas chaves legadas também são compatíveis com o byte de versão 0x00.
Observe que esse prefixo não é autenticado e não pode ser usado para fins de segurança propósitos. O Tink a usa como uma dica para acelerar a descriptografia ou verificação.
AEAD
Em geral, o Tink formata os textos criptografados AEAD como:
prefix || IV || ciphertext || tag
a menos que especificado de outra forma no RFC correspondente. prefix está vazio
ou um prefixo de saída Tink de 5 bytes.
AES-CTR-HMAC
Para o 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 do AD em bits representado como big-endian de 64 bits
inteiro não assinado. Esse esquema de HMAC segue o rascunho do AES-CBC-HMAC de
Mcgrew.
AEAD determinístico
O Tink implementa o RFC 5297 para AES-SIV, colocando a estrutura vetor de inicialização (SIV) no início do texto criptografado. O primitivo pode adicionar um prefixo de saída Tink de 5 bytes.
Enquanto o RFC 5297 suporta uma lista de dados associados, o Tink aceita apenas dados exatos um dado associado, o que corresponde a uma lista com um elemento na RFC 5297. Um dado associado vazio é uma lista com um elemento vazio e não um elemento vazio lista.
AEAD de streaming
Consulte HMAC de 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
Primitivas de AEAD do Tink. A criptografia funciona da seguinte maneira:
- Uma nova
DEKé gerada usando um determinado modelo ou parâmetros de chave. - O
DEKé serializado em uma string de bytes. O formato de serialização serialização do buffer de protocolo do proto do tipo de chave. Por exemplo, este é um mensagem serializada do buffer de protocoloAesGcmKeydefinida em aes_gcm.proto para a DEK do tipo de chave AES GCM. Consulte Serialização do buffer de protocolo para saber como serializar um buffer de protocolo. - O
DEKserializado é criptografado por um provedor externo (por exemplo, GCP). em umencrypted DEK. - O
DEKé usado para criptografar o texto simples com os dados associados emciphertext. Portanto,ciphertexttem exatamente o mesmo formato que o primitivo da AEAD. que corresponde aoDEK.
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 as RFCs correspondentes. Primitives podem adicionar uma saída do Tink de 5 bytes à tag.
PRF definido
O Tink segue as RFCs correspondentes. Observe que ao definir PRF, o tipo de chave é diferente do tipo de chave MAC do mesmo algoritmo por não incluir o comprimento da saída. As chaves PRF Set nunca adicionam um prefixo de saída do Tink. Isso garante que a saída seja realmente um PRF.
Criptografia híbrida
O formato geral de fio 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
as informações sobre quantos bytes analisar e como analisar esses bytes a partir
encapsulated_key:
HPKE (criptografia de chave pública híbrida)
O Tink segue o padrão HPKE definido na RFC 9180. Um pacote de criptografia HPKE inclui os três primitivos a seguir.
- Mecanismo de encapsulamento de chaves (KEM, na sigla em inglês)
- Função de derivação de chaves (KDF, na sigla em inglês)
- Criptografia autenticada com dados associados (AEAD)
O padrão HPKE não define um formato de distribuição geral na seção RFC 9180
10. A implementação HPKE da Tink usa o seguinte:
Valores encapsulated_key e encrypted_data.
encapsulated_key- Chave pública serializada do remetente
- Definido como
encem RFC 9180, seção 4.1 - Formato determinado pelo HPKE KEM específico usado
encrypted_data- Texto criptografado e tag (por exemplo,
ciphertext || tagsem o IV) - Definido como
ctem RFC 9180, seção 4 - Formato determinado pelo HPKE AEAD específico usado
- Texto criptografado e tag (por exemplo,
KEM X25519 baseado em Diffie-Hellman
Para DHKEMs X25519, o valor enc é o campo público Diffie-Hellman de 32 bytes do remetente.
de dados.
ECIES-AEAD-HKDF
Para a implementação 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).
KEM
Dependendo do tipo de chave, o Tink usa uma curva elíptica compactada e não compactada
seguindo os padrões de codificação RFC 8422/ANSI.X9-62.2005 (link em inglês). Para
pontos descompactados, o byte 0x04 será seguido por x e y.
coordenadas 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 é usada. Para o X25519,
é usada a definição RFC 7748 (coordenada x como número inteiro de tamanho fixo).
DEM
Para o encrypted_data, o Tink usa o mesmo formato do AEAD. Isso inclui
especificando um IV.
Derivação de chaves
Primeiro, a coordenada x x_ss do ponto compartilhado é calculada. A chave da
O AEAD é definido 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 KEM completa como bytes.
Assinaturas digitais
O Tink segue as RFCs correspondentes. Primitives podem adicionar uma saída do Tink de 5 bytes da 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 que tenham o mesmo tamanho em bytes da ordem da curva. Para
exemplo, para a curva NIST P-256, r e s são preenchidos com zeros para 32 bytes.
A assinatura DER é codificada usando ASN.1:
ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }
A codificação é:
0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s
A Tink segue as práticas recomendadas para a verificação de assinaturas e aceita apenas Assinaturas ECDSA codificadas por DER (assinaturas alternativas codificadas por BER são inválidas).
Isso ajuda a prevenir ataques de maleabilidade da assinatura, que muitas vezes afetam sistemas de criptomoedas.