ECDH este cunoscut ca a Mecanism de încapsulare cheie, care, după cum menționați, este similar cu criptarea cheii publice, dar nu este același.
Există multe motive pentru a prefera KEM-urile, o să menționez rapid unul.
În primul rând, rețineți că un KEM este (formal) un tuplu de trei algoritmi $(\mathsf{KGen}, \mathsf{Encaps}, \mathsf{DCaps})$, Unde
$\mathsf{KGen}$ ia ca intrare un parametru de securitate $1^\lambda$, și scoate o pereche de taste $(sk, pk)$
$\mathsf{Encaps}$ ia ca intrare o cheie publică $pk$ (și poate ceva aleatoriu, care este adesea doar implicit) și returnează o pereche $(k, c)$ a unei chei derivate $k$, și „text cifrat” $c$
$\mathsf{Decapsule}$ ia ca intrare o cheie secretă $sk$ și „text cifrat” $c$, și scoate o altă cheie derivată $k'$.
KEM-ul este corect dacă $k = k'$ în cele din urmă, de ex. cele două chei derivate sunt de acord.
Noțiunea de securitate a KEM-urilor este similară cu cea a PKE, ceea ce înseamnă că există o modalitate naturală de a extinde noțiunile tradiționale de securitate IND-CPA/IND-CCA.
Rețineți că se poate construi un KEM folosind orice PKE, având $\mathsf{Encaps}_{pk}(r) = \mathsf{Enc}_{pk}(r)$, Unde $r$ este aleatorietatea folosită de KEM (aceasta este ideea de „criptare uniform aleatorie a cheilor” pe care ați menționat-o).
Poate ar trebui să scriem în mod explicit $\mathsf{Enc}_{pk}(f(r))$ este o funcție a aleatoriei --- nu mă voi deranja să fiu acest lucru explicit.
Deci de ce să-i pese de KEM-uri?
Deși există și alte lucruri pe care le puteți menționa, a major Ideea este că există anumite proprietăți pe care KEM-urile „naturale” (cum ar fi ECDH) le au și că un KEM construit din abordarea „criptare chei aleatoare” le face nu avea.
Aceasta înseamnă că ECDH nu este „doar” un KEM și poate fi folosit în aplicații în care criptarea cheilor aleatoare nu funcționează.
Poate că proprietatea cea mai evidentă spre care trebuie indicată este „non-interactivitatea”.
În special, ECDH poate fi scris ca
- ambele părți schimbând o pereche de chei Diffie Hellman $(g, g^{s_i})$, și apoi
- calculând o funcție simplă a acestor perechi de taste.
Dacă încercăm să scriem asta cu sintaxa unui KEM, am putea spune asta $\mathsf{KGen}(1^\lambda)$ produce o pereche de chei $(g, s_0, g^{s_0})$, și asta $\mathsf{Encaps}_{g^{s_0}}(r) = (g, s_1, g^{s_1})$ produce o altă pereche de chei, în care modelăm „textul cifrat” ca $g^{s_1}$.
Aceasta are o foarte proprietate curioasă totuși --- $g^{s_1}$, „textul cifrat” al schemei, face nu depind de cheia publică (în afară de generatorul de grup $g$, care poate fi standardizat ca parametru public).
Aceasta este o proprietate destul de surprinzătoare și una pe care schema „criptare cheie aleatorie” nu o are.
Este cunoscut ca fiind o schemă de schimb de chei non-interactiv (NIKE).
Proprietatea este ambele
util în practică --- „Clichet dublu” al semnalului folosește această proprietate într-un mod cheie, ceea ce face dificilă „introducerea” unui alt KEM de utilizat pentru semnal și
teoretic non-trivial --- construirea generică a NIKE necesită unele primitive fanteziste, cum ar fi criptarea FHE/funcțională. Există rezultate cunoscute care arată că probabil că nu este posibil să construiești NIKE folosind grilaje (și în mod plauzibil coduri) cu „parametri mici”.
De fapt (excluzând schemele bazate pe zăbrele cu parametri mari), cunosc doar un NIKE post-cuantic, și anume CSIDH.Aceasta înseamnă că o modificare simplă a semnalului să fie post-cuantică
- folosește CSIDH,
- folosește o variantă mai puțin eficientă a unei scheme NIST PQC (să zicem o schemă bazată pe zăbrele cu parametri mici) sau
- modifică într-un fel protocolul Signal în sine, de obicei cu o anumită eficiență.
Deși există lucruri mai nuanțate pe care le puteți spune pentru a compara PKE și KEM-urile, teoretic există o foarte beneficiu mare pentru ECDH --- este un NIKE eficient, care nu sunt deloc obișnuite.
