In questa pagina viene descritto il formato dei cavi di Tink per le chiavi e l'output primitivo. La documentazione è rivolta ai crittografi che desiderano aggiungere altri linguaggi a Tink e ai gestori di altre librerie di crittografia di alto livello che desiderano una modalità compatibile con i cavi. Non è destinata a un pubblico generico.
Serializzazione del set di chiavi
Tink utilizza Google protobuf per serializzare i suoi set di chiavi.
- Un set di chiavi serializzato binario è un protocollo set di chiavi serializzato definito in tink.proto. La proprietà del valore KeyData di una chiave è un proto serializzato del tipo di chiave corrispondente.
- Un set di chiavi serializzato JSON è un protocollo di set di chiavi serializzato in formato JSON. Tieni presente che il valore KeyData è ancora un protocollo serializzato binario.
- Un set di chiavi criptato è un protocollo EncryptedKeyst serializzato definito in tink.proto. Contiene un set di chiavi serializzate binarie criptate e, facoltativamente, alcuni metadati KeysetInfo non criptati.
Prefisso output Tink
La maggior parte delle primitive Tink supporta un prefisso di output di 5 byte composto da:
- Versione a 1 byte:
0x01 - Suggerimento chiave di 4 byte: si tratta dell'ID 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. Tink lo usa come suggerimento per velocizzare la decrittografia o la verifica.
AEAD
In generale, Tink formatta i testi criptati AEAD come:
prefix || IV || ciphertext || tag
se non diversamente specificato nel documento RFC corrispondente. prefix è vuoto o è un prefisso di output Tink di 5 byte.
AES-CTR-HMAC
Per AES-CTR-HMAC, Tink calcola il MAC con i dati associati (AD) in questo modo:
AD || IV || ciphertext || bitlen(AD)
dove bitlen(AD) è la lunghezza di AD, espressa in bit, rappresentata come un numero intero senza segno
big-endian a 64 bit. Questo schema HMAC segue la bozza per AES-CBC-HMAC di Mcgrew.
AEAD deterministico
Tink implementa RFC 5297 per AES-SIV, inserendo il vettore di inizializzazione sintetico (SIV) all'inizio del testo crittografato. La primitiva potrebbe aggiungere un prefisso di output Tink di 5 byte.
Mentre RFC 5297 supporta un elenco di dati associati, Tink supporta solo uno dei dati associati, che corrisponde a un elenco con un elemento in RFC 5297. Un dato associato vuoto è un elenco con un elemento vuoto e non un elenco vuoto.
AEAD streaming
Vedi AES-CTR HMAC e AES-GCM-HKDF.
Crittografia envelope
La crittografia busta cripta i dati con una chiave di crittografia dei dati DEK utilizzando le primitive AEAD di Tink. La crittografia funziona come segue:
- Viene generato un nuovo
DEKutilizzando un determinato modello di chiave (o parametri chiave). DEKè serializzato in una stringa di byte. Il formato di serializzazione del protocollo di serializzazione del buffer del protocollo. Ad esempio, si tratta di un messaggio di buffer di protocolloAesGcmKeyserializzato definito in aes_gcm.proto per DEK del tipo di chiave AES GCM. Per informazioni su come serializzare un buffer di protocollo, consulta Serializzazione del buffer di protocollo.- L'elemento
DEKserializzato viene criptato da un provider esterno (ad esempio Google Cloud) in unencrypted DEK. DEKviene utilizzato per criptare il testo non crittografato con i dati associati inciphertext. Pertantociphertextha esattamente lo stesso formato della primitiva AEAD corrispondente alDEK.
Il formato di output della crittografia envelope è il seguente:
encrypted DEK length || encrypted DEK || ciphertext
encrypted DEK length è di 4 byte, che memorizza la lunghezza di encrypted DEK come numero intero big-endian a 32 bit.
MAC
Tink segue le specifiche RFC corrispondenti. Le primitive possono aggiungere un prefisso di output Tink di 5 byte al tag.
PRF impostato
Tink segue le specifiche RFC corrispondenti. Tieni presente che per l'impostazione PRF, il tipo di chiave è diverso dal tipo di chiave MAC dello stesso algoritmo perché non include la lunghezza dell'output. Le chiavi Set PRF non aggiungono mai un prefisso di output Tink. Questo garantisce che l'output siano effettivamente un PRF.
Crittografia ibrida
Il formato generale per la crittografia ibrida Tink è il seguente:
prefix || encapsulated_key || encrypted_data
prefix è vuoto o è un prefisso di output Tink di 5 byte. Ogni tipo di chiave contiene le informazioni sul numero di byte da analizzare e su come analizzarli da encapsulated_key.
HPKE (Hybrid Public Key Encryption)
Tink segue lo standard HPKE definito in RFC 9180. Un pacchetto di crittografia HPKE include le tre primitive seguenti.
- Meccanismo di incapsulamento della chiave (KEM)
- Funzione di derivazione della chiave (KDF)
- Crittografia autenticata con dati associati (AEAD)
Lo standard HPKE non definisce un formato di cablaggio generico nella RFC 9180, sezione 10. L'implementazione HPKE di Tink utilizza i seguenti
valori encapsulated_key e encrypted_data.
encapsulated_key- Chiave pubblica serializzata del mittente
- Definito come
encin RFC 9180, Sezione 4.1 - Formato determinato dallo specifico KEM HPKE utilizzato
encrypted_data- Testo crittografato e tag (ad es.
ciphertext || tagsenza l'IV) - Definito come
ctin RFC 9180, Sezione 4 - Formato determinato dallo specifico AEAD HPKE utilizzato
- Testo crittografato e tag (ad es.
X25519 KEM basato su Diffie-Hellman
Per i DHKEM X25519, il valore enc è la chiave pubblica Diffie-Hellman a 32 byte del mittente.
ECIES-AEAD-HKDF
Per l'implementazione ECIES-AEAD-HKDF di Tink, encapsulated_key è l'output del meccanismo di incapsulamento delle chiavi (KEM) e encrypted_data è l'output del meccanismo di incapsulamento dei dati (DEM).
KEM
A seconda del tipo di chiave, Tink utilizza punti a curva ellittica
compressi e non compressi, secondo gli standard di codifica RFC 8422/ANSI.X9-62.2005. Per i punti non compressi, il byte 0x04 è seguito dalla coordinata x e dalla coordinata y come numeri interi a dimensione fissa. Per le coordinate compresse, vengono utilizzati il byte 0x02 o 0x03 e la coordinata x come numero intero a dimensione fissa. Per X25519, viene utilizzata la definizione di RFC 7748 (coordinata x come numero intero a dimensione fissa).
DEM
Per encrypted_data, Tink utilizza lo stesso formato dell'AEAD. Ciò include
la specifica di una IV.
Derivazione della chiave
Innanzitutto viene calcolata la coordinata x x_ss del punto condiviso. La chiave per l'AEAD viene quindi impostata 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 sotto forma di byte.
Firme digitali
Tink segue le specifiche RFC corrispondenti. Le primitive possono aggiungere un prefisso di output Tink di 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 presentano spaziatura interna pari a zero e hanno le stesse dimensioni in byte dell'ordine della curva. Ad esempio, per la curva NIST P-256, r e s corrispondono a 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 alternative con codifica BER non sono valide).
Ciò aiuta a prevenire gli attacchi di Malleability alle firme, che spesso influiscono sui sistemi di criptovalute.