5. Hybrid Public Key Encryption (Crittografia ibrida a chiave pubblica)
5. Hybrid Public Key Encryption (Crittografia ibrida a chiave pubblica)
In questa sezione definiamo alcune varianti HPKE. Tutte le varianti accettano una chiave pubblica del destinatario e una sequenza di testi in chiaro pt e producono una chiave incapsulata enc e una sequenza di testi cifrati ct. Questi output sono costruiti in modo che solo il possessore di skR possa disincapsulare la chiave da enc e decifrare i testi cifrati. Tutti gli algoritmi accettano anche un parametro info che può essere utilizzato per influenzare la generazione di chiavi (ad esempio, per incorporare informazioni di identità) e un parametro aad che fornisce dati autenticati aggiuntivi all'algoritmo AEAD in uso.
Oltre al caso base della cifratura verso una chiave pubblica, includiamo tre varianti autenticate: una che autentica il possesso di una chiave pre-condivisa, una che autentica il possesso di una chiave privata KEM, e una che autentica il possesso sia di una chiave pre-condivisa che di una chiave privata KEM. Tutte le varianti autenticate contribuiscono materiale di chiavi aggiuntivo all'operazione di cifratura. I seguenti valori di un byte saranno utilizzati per distinguere tra le modalità:
| Mode (Modalità) | Value (Valore) | |===============|===============| | mode_base | 0x00 | | mode_psk | 0x01 | | mode_auth | 0x02 | | mode_auth_psk | 0x03 |
Table 1: HPKE Modes (Tabella 1: Modalità HPKE)
Tutti questi casi seguono lo stesso schema di base in due fasi:
-
Stabilire un contesto di cifratura condiviso tra mittente e destinatario.
-
Utilizzare quel contesto per cifrare o decifrare il contenuto.
Un context (contesto) è una struttura specifica dell'implementazione che codifica l'algoritmo AEAD e la chiave in uso, e gestisce i nonce utilizzati in modo che lo stesso nonce non sia utilizzato con più testi in chiaro. Ha anche un'interfaccia per esportare valori segreti, come descritto nella Sezione 5.3. Vedere la Sezione 5.2 per una descrizione di questa struttura e delle sue interfacce. La decifrazione HPKE fallisce quando la decifrazione AEAD sottostante fallisce.
Le costruzioni descritte qui presumono che i parametri non privati rilevanti (enc, psk_id, ecc.) siano trasportati tra mittente e destinatario da qualche applicazione che utilizza HPKE. Inoltre, un destinatario con più di una chiave pubblica necessita di un modo per determinare quale delle sue chiavi pubbliche è stata utilizzata per l'operazione di incapsulamento. Ad esempio, le applicazioni possono inviare queste informazioni insieme a un testo cifrato dal mittente al destinatario. La specifica di tale meccanismo è lasciata all'applicazione. Vedere la Sezione 10 per ulteriori dettagli.
Si noti che alcuni KEM potrebbero non supportare AuthEncap() o AuthDecap(). Per tali KEM, sono supportati solo mode_base o mode_psk. Le specifiche future che definiscono nuovi KEM DEVONO indicare se queste modalità sono supportate. Vedere la Sezione 7.1.5 per ulteriori dettagli.
Le procedure descritte in questa sezione sono presentate in uno pseudocodice simile a Python. Gli algoritmi utilizzati sono lasciati impliciti.