9.1.2. Computational Analysis (Analisi computazionale)

9.1.2. Analisi computazionale

È mostrato in [CS01] che uno schema di cifratura a chiave pubblica ibrido essenzialmente della stessa forma della modalità Base descritta qui è IND-CCA2-sicuro finché gli schemi KEM e AEAD sottostanti sono IND-CCA2-sicuri. Inoltre, è mostrato in [HHK06] che la sicurezza IND-CCA2 del KEM e del meccanismo di incapsulamento dei dati sono condizioni necessarie per ottenere la sicurezza IND-CCA2 per la cifratura a chiave pubblica ibrida. La principale differenza tra lo schema proposto in [CS01] e la modalità Base in questo documento (entrambi denominati HPKE) è che interponiamo alcune chiamate KDF tra il KEM e l'AEAD. L'analisi dell'istanziazione della modalità Base HPKE in questo documento richiede quindi di verificare che le chiamate KDF aggiuntive non causino il fallimento della proprietà IND-CCA2, nonché di verificare la proprietà aggiuntiva di segretezza della chiave di esportazione.

L'analisi delle modalità PSK, Auth e AuthPSK definite in questo documento richiede inoltre di verificare la proprietà di autenticazione del mittente. Mentre la modalità PSK aggiunge semplicemente materiale di chiave supplementare alla pianificazione delle chiavi, le modalità Auth e AuthPSK utilizzano una costruzione KEM autenticata non standard. In generale, le modalità autenticate di HPKE possono essere viste e analizzate come varianti di signcryption [SigncryptionDZ10].

Un'analisi computazionale preliminare di tutte le modalità HPKE è stata effettuata in [HPKEAnalysis], indicando sicurezza asintotica per il caso in cui il KEM è DHKEM, l'AEAD è qualsiasi schema IND-CPA-sicuro e INT-CTXT-sicuro, e il gruppo DH e il KDF soddisfano le seguenti condizioni:

• Gruppo DH: Il problema Diffie-Hellman gap (GDH) è difficile nel sottogruppo appropriato [GAP].

• Extract() ed Expand(): Extract() può essere modellato come un oracolo casuale. Expand() può essere modellato come una funzione pseudocasuale, dove il primo argomento è la chiave.

In particolare, i KDF e i gruppi DH definiti in questo documento (vedere Sezioni 7.2 e 7.1) soddisfano queste proprietà quando utilizzati come specificato. L'analisi in [HPKEAnalysis] dimostra che sotto questi vincoli, HPKE continua a fornire sicurezza IND-CCA2 e fornisce le proprietà aggiuntive sopra menzionate. Inoltre, l'analisi conferma che le proprietà attese valgono nei diversi casi di compromissione della chiave menzionati sopra. L'analisi considera un mittente che invia un messaggio utilizzando il contesto di cifratura e inoltre esporta due segreti indipendenti utilizzando l'interfaccia di esportazione dei segreti.

La tabella seguente riassume i risultati principali da [HPKEAnalysis]. N/A significa che una proprietà non si applica per la modalità data, mentre Y significa che la modalità data soddisfa la proprietà.

Variante	Segr. mess.	Segr. export	Auth. mitt.
Base	Y	Y	N/A
PSK	Y	Y	Y
Auth	Y	Y	Y
AuthPSK	Y	Y	Y

Tabella 6: Proprietà di sicurezza delle modalità HPKE

Se KEM non basati su DH devono essere utilizzati con HPKE, sarà necessaria un'ulteriore analisi per provare la loro sicurezza. I risultati da [CS01] forniscono alcune indicazioni che qualsiasi KEM IND-CCA2-sicuro sarà sufficiente qui, ma non sono conclusivi date le differenze negli schemi.

Un'analisi computazionale dettagliata dell'API di cifratura a singola esecuzione della modalità Auth di HPKE è stata effettuata in [ABHKLR20]. Il documento definisce nozioni di sicurezza per i KEM autenticati e per la cifratura a chiave pubblica autenticata, utilizzando la terminologia di sicurezza outsider e insider nota dalla signcryption [SigncryptionDZ10]. L'analisi prova che l'interfaccia AuthEncap()/AuthDecap() di DHKEM soddisfa queste nozioni per tutti i gruppi Diffie-Hellman specificati in questo documento. L'analisi fornisce anche limiti di sicurezza esatti, sotto le ipotesi che il problema Diffie-Hellman gap (GDH) sia difficile nel sottogruppo appropriato [GAP], e che HKDF possa essere modellato come un oracolo casuale.

Inoltre, [ABHKLR20] prova teoremi di composizione, mostrando che la modalità Auth di HPKE soddisfa le nozioni di sicurezza della cifratura a chiave pubblica autenticata per tutti i KDF e gli schemi AEAD specificati in questo documento, dato qualsiasi KEM autenticato che soddisfi le nozioni di sicurezza precedentemente definite per i KEM autenticati. I teoremi assumono che il KEM sia perfettamente corretto; potrebbero essere facilmente adattati per funzionare con KEM che hanno una probabilità non nulla ma trascurabile di fallimento della decifratura. Le ipotesi sul KDF sono che Extract() ed Expand() possano essere modellati come funzioni pseudocasuali dove il primo argomento è la chiave, rispettivamente. L'ipotesi per l'AEAD è la sicurezza IND-CPA e IND-CTXT.

In sintesi, l'analisi in [ABHKLR20] prova che l'API di cifratura a singola esecuzione della modalità Auth di HPKE soddisfa le proprietà desiderate di riservatezza dei messaggi e autenticazione del mittente elencate all'inizio di questa sezione; non considera più messaggi, né l'API di esportazione dei segreti.