5.1.3 Authentication Using an Asymmetric Key (Autenticazione utilizzando una chiave asimmetrica)

5.1.3 Authentication Using an Asymmetric Key (Autenticazione utilizzando una chiave asimmetrica)

Questa variante estende il meccanismo di base permettendo al destinatario di autenticare che il mittente possedesse una data chiave privata KEM. Questo perché AuthDecap(enc, skR, pkS) produce il segreto condiviso KEM corretto solo se il valore incapsulato enc è stato prodotto da AuthEncap(pkR, skS), dove skS è la chiave privata corrispondente a pkS. In altre parole, al massimo due entità (precisamente due, nel caso di DHKEM) avrebbero potuto produrre questo segreto, quindi se il destinatario è al massimo uno, allora il mittente è l'altro con probabilità schiacciante.

La differenza principale dal caso base è che le chiamate a Encap() e Decap() sono sostituite da chiamate a AuthEncap() e AuthDecap(), che aggiungono la chiave pubblica del mittente alla loro stringa di contesto interna. I parametri della funzione pkR e pkS sono chiavi pubbliche, ed enc è un segreto condiviso KEM incapsulato.

Ovviamente, questa variante può essere utilizzata solo con un KEM che fornisce le procedure AuthEncap() e AuthDecap().

Questo meccanismo autentica solo la coppia di chiavi del mittente, non qualsiasi altro identificatore. Se un'applicazione desidera legare i testi cifrati HPKE o i segreti esportati a un'altra identità per il mittente (ad esempio, un indirizzo e-mail o un nome di dominio), allora questo identificatore dovrebbe essere incluso nel parametro info per evitare problemi di errata associazione dell'identità [IMB].

def SetupAuthS(pkR, info, skS):
  shared_secret, enc = AuthEncap(pkR, skS)
  return enc, KeyScheduleS(mode_auth, shared_secret, info,
                           default_psk, default_psk_id)

def SetupAuthR(enc, skR, info, pkS):
  shared_secret = AuthDecap(enc, skR, pkS)
  return KeyScheduleR(mode_auth, shared_secret, info,
                      default_psk, default_psk_id)