Questa pagina descrive il formato di trasmissione di Tink per le chiavi e l'output primitivo. La documentazione è rivolta ai crittografisti che vogliono aggiungere altre lingue a Tink e ai manutentori di altre librerie di crittografia di alto livello che vogliono una modalità compatibile con Wire. Non è destinato al pubblico generico.
Serializzazione del set di chiavi
Tink utilizza Google protobuf per serializzare i set di chiavi.
- Un set di chiavi serializzato in formato binario è un proto Keyset serializzato definito in tink.proto. La proprietà del valore KeyData di una chiave è un proto serializzato del tipo di chiave corrispondente.
- Un keyset serializzato in JSON è un proto Keyset serializzato in formato JSON. Tieni presente che il valore KeyData è ancora un proto serializzato binario.
- Un set di chiavi criptato è un proto EncryptedKeyset serializzato definito in tink.proto. Contiene un insieme 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 di 5 byte composto da:
- Versione 1 byte:
0x01 - Suggerimento chiave di 4 byte: si tratta dell'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 considerato attendibile per motivi di sicurezza. Tink lo utilizza come suggerimento per velocizzare la decrittografia o la verifica.
AEAD
In generale, Tink formatta le cifre AEAD come:
prefix || IV || ciphertext || tag
salvo diversa indicazione nell'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) come segue:
AD || IV || ciphertext || bitlen(AD)
dove bitlen(AD) è la lunghezza dell'annuncio in bit rappresentata come numero intero non firmato a 64 bit in big endian. 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 cifrato. L'elemento primitivo potrebbe aggiungere un prefisso di output Tink di 5 byte.
Sebbene RFC 5297 supporti un elenco di dati associati, Tink supporta solo esattamente un dato associato, che corrisponde a un elenco con un elemento in RFC 5297. Dati associati vuoti è un elenco con un elemento vuoto e non un elenco vuoto.
AEAD in streaming
Vedi AES-CTR HMAC e AES-GCM-HKDF.
Crittografia envelope
La crittografia dell'involucro cripta i dati con una chiave di crittografia dei dati DEK utilizzando le primitive AEAD di Tink. La crittografia funziona nel seguente modo:
- Viene generato un nuovo
DEKutilizzando un determinato modello di chiave (o parametri chiave). DEKviene serializzato in una stringa di byte. Il formato di serializzazione della serializzazione del buffer di protocollo del tipo di chiave proto. Ad esempio, si tratta di un messaggio Protocol BufferAesGcmKeyserializzato definito in aes_gcm.proto per la DEK di tipo di chiave AES GCM. Per informazioni su come serializzare un buffer di protocollo, consulta la sezione Serializzazione dei buffer di protocollo.- Il
DEKserializzato viene criptato da un fornitore esterno (ad esempio Google Cloud) in unencrypted DEK. DEKviene utilizzato per criptare il testo non criptato con i dati associati inciphertext. Pertanto,ciphertextha lo stesso formato della primitiva AEAD corrispondente aDEK.
Il formato di output della crittografia envelope è il seguente:
encrypted DEK length || encrypted DEK || ciphertext
encrypted DEK length è costituito da 4 byte che memorizzano la lunghezza di encrypted DEK come numero intero big endian a 32 bit.
MAC
Tink segue le RFC corrispondenti. I primi possono aggiungere un prefisso di output Tink di 5 byte al tag.
Set PRF
Tink segue le RFC corrispondenti. Tieni presente che per l'insieme PRF il tipo di chiave è diverso da quello della chiave MAC dello stesso algoritmo perché non include la lunghezza dell'output. Le chiavi del set PRF non aggiungono mai un prefisso di output Tink. In questo modo, l'output è effettivamente un file PRF.
Crittografia ibrida
Il formato generale del cavo per la crittografia ibrida di 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 su quanti byte analizzare e su come analizzarli da encapsulated_key.
HPKE (Hybrid Public Key Encryption)
Tink segue lo standard HPKE definito nel documento RFC 9180. Una suite di crittografia HPKE include le seguenti tre primitive.
- 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 generale per i dati in 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
- Definite come
encnella RFC 9180, sezione 4.1 - Formato determinato dal KEM HPKE specifico utilizzato
encrypted_data- Testo criptato e tag (ad es.
ciphertext || tagsenza IV) - Definito come
ctnella sezione 4 del documento RFC 9180 - Formato determinato dall'AEAD HPKE specifico utilizzato
- Testo criptato e tag (ad es.
KEM basato su Diffie-Hellman X25519
Per le chiavi DHKEM X25519, il valore enc è la chiave pubblica Diffie-Hellman di 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 di curve ellittiche compressi e non compressi, in base agli standard di codifica RFC 8422/ANSI.X9-62.2005. Per i punti non compressi, il byte 0x04 è seguito dalle coordinate x e y come numeri interi di dimensioni fisse. Per le coordinate compresse, viene utilizzato il byte 0x02
o 0x03 e la coordinata x come numero intero di dimensioni fisse. Per X25519 viene utilizzata la definizione della RFC 7748 (coordinate x come numero intero di dimensioni fisse).
DEM
Per encrypted_data, Tink utilizza lo stesso formato dell'AEAD. È inclusa anche la specifica di un IV.
Derivazione delle chiavi
Innanzitutto viene calcolata la coordinata x x_ss del punto condiviso. La chiave per il
AEAD viene impostata su:
HKDF(ikm = encapsulated_key || x_ss, salt = salt_of_key, info = context_info, length = dem_key_size)
dove encapsulated_key è l'output completo del KEM in byte.
Firme digitali
Tink segue le RFC corrispondenti. I primi 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 sono con spaziatura zero e hanno le stesse dimensioni in byte dell'ordine della curva. Ad esempio, per la curva NIST P-256, r e s sono riempiti con zeri 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 delle firme, accettando solo firme ECDSA con codifica DER (le firme con codifica BER alternativa non sono valide).
In questo modo è possibile evitare attacchi di malleabilità della firma, che spesso colpiscono i sistemi di criptovaluta.