Formato cavo Tink

Questa pagina descrive il formato del cavo di Tink per le chiavi e l'output primitivo. La è rivolta ai crittografi che desiderano aggiungere altre lingue Tink e manutentori di altre librerie crittografiche di alto livello che vogliono un cavo compatibile. Non è destinata a un pubblico generico.

Serializzazione del set di chiavi

Tink utilizza protobuf di Google per serializzare i suoi set di chiavi.

  • Un set di chiavi serializzato binario è un protocollo di set di chiavi serializzato definito in tink.proto. La proprietà del valore KeyData di una chiave è un del tipo di chiave corrispondente.
  • Un set di chiavi serializzato JSON è un proto Keyset serializzato in formato JSON. Tieni presente che il valore KeyData è comunque un protocollo serializzato binario.
  • Un set di chiavi criptato è un protocollo EncryptedKeyst serializzato definito in tink.proto. Contiene un set di chiavi serializzato binario criptato e, facoltativamente, alcuni metadati KeysetInfo non criptati.

Prefisso output Tink

La maggior parte delle primitive Tink supporta un prefisso di output a 5 byte composto da:

  • Versione a 1 byte: 0x01
  • Suggerimento chiave 4 byte: questo è l'ID chiave della chiave utilizzata.

Alcune chiavi precedenti potrebbero supportare anche il byte di versione 0x00.

Tieni presente che questo prefisso non è autenticato e non può essere utilizzato per motivi di sicurezza scopi. Tink lo utilizza come suggerimento per velocizzare la decriptazione o la verifica.

AEAD

In generale, Tink formatta i testi crittografati AEAD come:

prefix || IV || ciphertext || tag

se non diversamente specificato nella RFC corrispondente. Il campo prefix è vuoto o un prefisso di output Tink da 5 byte.

AES-CTR-HMAC

Per AES-CTR-HMAC, Tink calcola il MAC con i dati associati (AD) come segue:

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

dove bitlen(AD) è la lunghezza in bit dell'annuncio, rappresentata da un big-endian a 64 bit senza segno. Questo schema HMAC segue la bozza per AES-CBC-HMAC di Mcgrew.

AEAD deterministico

Tink implementa RFC 5297 per AES-SIV, inserendo i dati sintetici vettore di inizializzazione (SIV) all'inizio del testo crittografato. La primitiva può aggiungere un prefisso di output Tink a 5 byte.

Mentre RFC 5297 supporta un elenco di dati associati, Tink supporta solo a un dato associato, che corrisponde a un elenco con un elemento in RFC 5297. Un dato associato vuoto è un elenco con un elemento vuoto e non uno vuoto dall'elenco di lettura.

AEAD streaming

Vedi AES-CTR HMAC e AES-GCM-HKDF.

Crittografia envelope

La crittografia della busta cripta i dati con una chiave di crittografia dei dati DEK utilizzando Le primitive dell'AEAD di Tink. La crittografia funziona come segue:

  • Viene generato un nuovo DEK utilizzando un determinato modello di chiave (o parametri chiave).
  • DEK è serializzato in una stringa di byte. Il formato di serializzazione serializzazione del buffer di protocollo del protocollo del tipo di chiave. Ad esempio, si tratta di un messaggio del buffer di protocollo AesGcmKey serializzato definito in aes_gcm.proto per DEK di tipo di chiave AES GCM. Per informazioni su come serializzare, consulta la sezione Serializzazione del buffer di protocollo. un buffer di protocollo.
  • Il DEK serializzato è criptato da un provider esterno (ad esempio, Google Cloud), in un encrypted DEK.
  • DEK viene utilizzato per criptare il testo non crittografato con i dati associati in ciphertext. Quindi ciphertext ha esattamente lo stesso formato della primitiva AEAD corrispondente a DEK.

Il formato di output della crittografia envelope è il seguente:

encrypted DEK length || encrypted DEK || ciphertext

Il encrypted DEK length è di 4 byte e memorizza la lunghezza dell'elemento encrypted DEK come un numero intero big-endian a 32 bit.

MAC

Tink segue gli RFC corrispondenti. Le primitive possono aggiungere un output Tink a 5 byte al tag.

PRF impostato

Tink segue gli RFC corrispondenti. Tieni presente che per PRF Set il tipo di chiave è diverso dal tipo di chiave MAC dello stesso algoritmo, escludendo la lunghezza dell'output. Le chiavi PRF Set non aggiungono mai un prefisso di output Tink. Ciò garantisce che l'output sia una PRF.

Crittografia ibrida

Il formato generale del cavo per la crittografia ibrida Tink è il seguente:

prefix || encapsulated_key || encrypted_data

prefix è vuoto o è un prefisso di output Tink da 5 byte. Ogni tipo di chiave contiene le informazioni su quanti byte analizzare e su come analizzarli encapsulated_key.

HPKE (Hybrid Public Key Encryption)

Tink è conforme allo standard HPKE definito nel documento RFC 9180. Una suite di crittografia HPKE include le tre primitive seguenti.

  • Meccanismo di incapsulamento delle chiavi (KEM)
  • Funzione di derivazione della chiave (KDF)
  • Crittografia autenticata con dati associati (AEAD)

Lo standard HPKE non definisce un formato di cavo generale in RFC 9180, sezione 10. L'implementazione HPKE di Tink utilizza quanto segue Valori di encapsulated_key e encrypted_data.

  • encapsulated_key
    • Chiave pubblica serializzata del mittente
    • Definito come enc in RFC 9180, Sezione 4.1
    • Formato determinato dallo specifico HPKE KEM utilizzato
  • encrypted_data
    • Testo crittografato e tag (ad es. ciphertext || tag senza IV)
    • Definito come ct in RFC 9180, Sezione 4
    • Formato determinato dallo specifico AEAD HPKE utilizzato
KEM X25519 basato su Diffie-Hellman

Per i DHKEM X25519, il valore enc corrisponde al pubblico Diffie-Hellman da 32 byte del mittente chiave.

ECIES-AEAD-HKDF

Per l'implementazione ECIES-AEAD-HKDF di Tink, encapsulated_key è l'output del meccanismo di incapsulamento chiave (KEM) e encrypted_data è l'output del meccanismo di incapsulamento dei dati (DEM).

KEM

A seconda del tipo di tasto, Tink utilizza una curva ellittica compressa e non compressa secondo gli standard di codifica RFC 8422/ANSI.X9-62.2005. Per punti non compressi, il byte 0x04 è seguito da x e y come numeri interi a dimensione fissa. Per le coordinate compresse, il byte 0x02 o 0x03 e viene utilizzata la coordinata x come numero intero a dimensione fissa. Per X25519, Viene utilizzata la definizione RFC 7748 (coordinata x come numero intero a dimensione fissa).

DEM

Per encrypted_data, Tink utilizza lo stesso formato dell'AEAD. Sono inclusi che specifica un IV.

Derivazione della chiave

Innanzitutto viene calcolata la coordinata x x_ss del punto condiviso. La chiave per il L'AEAD viene quindi impostato su:

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

dove encapsulated_key è l'output KEM completo come byte.

Firme digitali

Tink segue gli RFC corrispondenti. Le primitive possono aggiungere un output Tink a 5 byte al tag generato.

ECDSA

A seconda del campo EcdsaSignatureEncoding nella chiave, il formato di una firma ECDSA è IEEE P1363 o ASN.1 DER.

Il formato della firma IEEE P1363 è r || s, dove r e s sono e hanno le stesse dimensioni in byte dell'ordine della curva. Per Ad esempio, per la curva NIST P-256, r e s sono riempiti da zero fino a 32 byte.

La firma DER è codificata utilizzando ASN.1:

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

In particolare, la codifica è:

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

Tink segue le best practice per la verifica della firma, accettando solo Firme ECDSA con codifica DER (le firme con codifica BER alternative non sono valide).

Ciò aiuta a prevenire gli attacchi alla meravigliabilità delle firme, che spesso influiscono sistemi di criptovalute.