5.1.3 Authentication Using an Asymmetric Key (Authentification à l'aide d'une clé asymétrique)

5.1.3 Authentication Using an Asymmetric Key (Authentification à l'aide d'une clé asymétrique)

Cette variante étend le mécanisme de base en permettant au destinataire d'authentifier que l'émetteur possédait une clé privée KEM donnée. Cela est dû au fait que AuthDecap(enc, skR, pkS) ne produit le secret partagé KEM correct que si la valeur encapsulée enc a été produite par AuthEncap(pkR, skS), où skS est la clé privée correspondant à pkS. En d'autres termes, au plus deux entités (précisément deux, dans le cas de DHKEM) auraient pu produire ce secret, donc si le destinataire est au plus l'une d'elles, alors l'émetteur est l'autre avec une probabilité écrasante.

La différence principale par rapport au cas de base est que les appels à Encap() et Decap() sont remplacés par des appels à AuthEncap() et AuthDecap(), qui ajoutent la clé publique de l'émetteur à leur chaîne de contexte interne. Les paramètres de fonction pkR et pkS sont des clés publiques, et enc est un secret partagé KEM encapsulé.

De toute évidence, cette variante ne peut être utilisée qu'avec un KEM qui fournit les procédures AuthEncap() et AuthDecap().

Ce mécanisme authentifie uniquement la paire de clés de l'émetteur, pas tout autre identifiant. Si une application souhaite lier des textes chiffrés HPKE ou des secrets exportés à une autre identité pour l'émetteur (par exemple, une adresse e-mail ou un nom de domaine), alors cet identifiant devrait être inclus dans le paramètre info pour éviter les problèmes de liaison d'identité incorrecte [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)