Pot scăpa cu generarea k (și d) de 512 biți pentru ECDSA pe baza P-521?

Am implementat o bibliotecă de criptografie hobbyist și sunt în partea în care este implementată criptografia cu curbă eliptică. Am implementat și testat deja ECDSA cu P-256 și P-384, unde cheile private statice și efemere sunt de 256 de biți și 384 de biți fiecare, până acum e bine.

Ceea ce mă deranjează este P-521. Plănuiesc să generez statică de 512 biți ($d$) și chei efemere ($k$) pentru a ușura implementarea, deoarece majoritatea funcțiilor hash (excluzând XOF-urile) au o ieșire de cel mult 512 biți (nu folosesc funcții hash pentru a genera direct cheile, doar aloc spațiu de stivă în funcție de lungimea de ieșire a funcțiilor hash obișnuite ).

Dacă fac asta, componenta de semnătură rezultată $s$ poate avea un fel de părtinire, dar din moment ce produsul de $d \cdot k^{-1}$ se va revarsa $n$, am pseudo-convingerea că aceasta nu este o problemă prea serioasă.

Așa că pun 2 întrebări legate:

Î1: pot scăpa cu generarea de chei statice și efemere de 512 biți pentru ECDSA peste P-521 și să nu dăunez securității?

Q2: pentru cazul general, dat un modul prim $n$, se dă un adversar $s = k \cdot r + d \pmod n$ și $r$, Unde $d$ este static și $r$ este calculat aleatoriu determinist din $k$; ambii $k$ și $d$ au mai putin de $\lceil {\log_2{n} \over 4} \rceil$ din bucăți de vârf tăiate; poate adversarul să obțină vreo parte din $d$ sau $k$?

Nu! Chiar și generarea unui 520 de biți $k$ este probabil o vulnerabilitate exploatabilă.

Un rezultat din 2020 pe această temă este LadderLeak: Ruperea ECDSA cu mai puțin de un bit de scurgere nonce. §5 discută despre estimarea costului pentru atac: nu este chiar fezabil pentru o prejudecată pe un singur bit dincolo de P256, dar prejudecățile mai mari permit atacuri mai ieftine, iar atacurile se îmbunătățesc doar cu timpul.

Utilizare ECDSA deterministă cu excepția cazului în care aveți un motiv întemeiat să utilizați ECDSA randomizat. ECDSA determinist poate folosi HMAC_DRBG ca o cutie neagră: trebuie doar să instanțiați HMAC_DRBG cu parametrii necesari. Un avantaj al acestui algoritm determinist este că, dacă testele dumneavoastră cu răspunsuri cunoscute dau rezultatele așteptate, aveți o cantitate destul de mare de încredere că l-ați implementat corect.Majoritatea sistemelor care fac semnături au oricum un RNG, iar HMAC_DRBG este un DRBG destul de bun (nu cel mai rapid, dar relativ ușor de implementat și compatibil cu FIPS).

Dacă utilizați ECDSA randomizat, vă recomand să îl implementați făcând ECDSA determinist și introducând un plus de aleatorie în HMAC_DRBG. În acest fel, dacă faceți greșit partea aleatorie, în cel mai rău caz se va degrada la ECDSA determinist, fără niciun risc de a scurge nonce. Există două motive pentru care ați putea prefera ECDSA randomizat: dacă este un obiectiv de securitate, un adversar nu poate spune dacă două semnături produse separat se întâmplă să fie pentru același mesaj (un obiectiv de securitate neobișnuit) sau pentru că poate crea anumite canale secundare sau punctele slabe de injectare a erorilor mai greu de exploatat (pe de altă parte, poate face, de asemenea, unele puncte slabe mai ușor de exploatat).