Deci, să presupunem că faceți acest lucru local (deci fără zgomot de rețea) și cunoașteți și specificul exact al procesorului dvs.
Bine. Acesta este un model de atac plauzibil, de exemplu, dacă atacatorul rulează un anunț JavaScript în browserul dvs. sau are o mașină virtuală amplasată pe același nor.
Este posibil să descoperiți cheia privată (în timp ce aveți acces la cheia publică) generată de libsodium pe baza timpului necesar pentru a genera o pereche de chei?
Utilizări de libsodiu Curba25519 taste curbe eliptice. O cheie privată Curve25519 este un șir de biți aleatoriu de o anumită lungime. (Este extins la un șir de octeți în care anumiți biți au valori fixe, dar asta nu adaugă un canal lateral de sincronizare.) Deci procesul de generare a cheii private este banal. Singurul canal lateral plauzibil se află în generatorul aleator în sine.
Unii algoritmi de generare aleatorie folosesc primitive care sunt susceptibile la canalele laterale de sincronizare. În special, CTR_DRBG se bazează pe AES, care este vulnerabil la atacurile de sincronizare a memoriei cache dacă este implementat în software într-un mod rapid naiv. CTR_DRBG rotește cheia AES foarte des, ceea ce o face oarecum mai puțin vulnerabilă decât în scenariile în care adversarul poate observa criptări cu aceeași cheie AES. In orice caz, un astfel de atac poate fi practic, cel putin in conditii ideale.
Cu alți algoritmi populari DRBG (de exemplu, Hash_DRBG sau HMAC_DRBG), cu o implementare AES fără tabele (de ex.folosind accelerarea hardware, cum ar fi AES-NI, sau utilizarea bit-slicing în software), sau dacă DRBG citește entropia suficient de des (ceea ce este fezabil pe hardware-ul modern cu un TRNG dedicat, cum ar fi RDRAND pe procesoare Intel sau echivalentul pe diferite smartphone-uri procesoare), atacurile de sincronizare asupra RNG nu sunt o preocupare.
Ceea ce ar putea fi mai vulnerabil este calculul cheii publice din cheia privată. Curve25519 face relativ ușor de implementat aritmetica fără canale laterale de sincronizare, dar nu este un lucru dat.
Cum rămâne cu alți algoritmi, cât de fezabil este acest lucru în general?
Cu curbele eliptice Weierstrass și cu Diffie-Hellman cu câmp finit, o cheie privată este un număr între $2$ și $P-2$. În afară de atacurile RNG, așa cum sa discutat mai devreme, implementarea naturală a procesului de generare a cheilor nu este susceptibilă la atacuri de sincronizare. Cu toate acestea, calculul cheii publice este vulnerabil la atacuri de sincronizare dacă este implementat fără precauții.
Cu RSA, generarea cheilor este un proces complex care implică testarea (pseudo-)primalității și o aritmetică suplimentară care este potențial vulnerabilă la atacurile de sincronizare. Concret, în practică, se pare că pasul care este cel mai predispus la scurgeri este calculul GCD făcut pentru a verifica asta $p-1$ și $q-1$ sunt co-prim cu exponentul public.
