Puncte:1

Cum se verifică puterea de securitate a k aleatoriu dacă k este un parametru de intrare al funcției de generare a semnăturii ECDSA folosind openssl-fips

drapel pe

După cum am înțeles,

1. Puterea de securitate este specificată în biți conform https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf

2. Puterea securității depinde de lungimea intrării entropiei atunci când se generează un număr aleator

Deci, în funcția de generare a semnăturii, dacă k aleatoriu este un parametru de intrare (nu se generează k aleatoriu în această funcție)

Cum se verifică k valid? puterea de securitate aleatoare k?

1, verificați doar numărul de biți aleatoriu k ?

2, Alte teste?

Mulțumiri

Puncte:4
drapel ng

În definiția standard a ECDSA, nonce $k$ ar trebui să fie un întreg secret uniform aleatoriu în interval $[1,n)$, Unde $n$ este ordinul principal al generatorului. Analiza perechilor mesaj/semnătură când $k$ este cunoscută sau are un defect (cum ar fi o părtinire sau o tendință de a se repeta) poate scurge cheia privată, astfel generarea de $k$ contează pentru securitate.

Nu este posibil ca o implementare a generării semnăturii ECDSA să verifice în mod semnificativ dacă valoarea unui intrare $k$ pe care îl primește este potrivit pentru utilizare în siguranță asa cum este prescris în definiția standard a semnăturii ECDSA, pentru că nu există nicio modalitate de a spune dintr-o valoare dacă este secretă sau nu, ceea ce este o calitate esențială $k$ ar trebui să posede. De asemenea, este imposibil de evaluat dacă un dat $k$ este aleatoriu, după cum sugerează întrebarea, cel puțin dacă nu știm cum a fost produs. Și oricum, în context, a fi aleatoriu este secundar față de a fi secret.

Prin urmare, mai degrabă decât să accepte $k$ ca intrare, procedura comună este de a face generarea unei aleatorii $k$ parte a implementării generării semnăturii ECDSA. O procedură de bază (dacă nu neapărat recomandată) este de a desena $\lceil\log_2(n)\rceil$ biți dintr-un RNG presupus puternic criptografic (cum ar fi /dev/urandom) și interpretează acești biți ca un număr întreg $k$ de ex. convenția big-endian, până se ține $0<k<n$ (ceea ce pentru mulți $n$ folosit în practică este în esență întotdeauna, deoarece $n$ este chiar sub o putere de doi). Nu iau în considerare această procedură de bază în restul răspunsului (chiar dacă acest lucru cometariu sugerează că acesta a fost miezul întrebării).

Este posibil să se modifice procedura de generare a semnăturii ECDSA pentru a utiliza în siguranță orice $k$ primeste. În loc de $k$, generarea semnăturii poate folosi $k':=f(d_U,H,k)$ Unde $d_U$ este cheia privată, $H$ este hash-ul mesajului de semnat și $f$ este o funcție de derivare a cheii publice care utilizează $d_U$ ca cheie principală, cu ieșire aproape de uniformă în $[1,n)$ Unde $n$ este ordinul generatorului. O astfel de practică nu încalcă compatibilitatea în niciun fel și este detectabilă doar cu ambele $k$ și cheia privată (pe lângă alte informații publice). Pentru $n$ până la 384 de biți cel puțin, o funcție potrivită ar fi $$k':=1+(\operatorname{HMAC-SHA-512}(d_U,H\mathbin\|k)\bmod(n-1))$$

Notă: în teorie, procedura de semnare are un număr de „întoarcere la Pasul 1” care va reinvoca $f$ și așteptați-vă la altceva $k'$, și nu voi primi asta.Cu toate acestea, acest lucru este discutabil, deoarece probabilitatea de re-invocare a $f$ este complet neglijabilă și nu poate fi testată chiar și cu controlul $d_U$, $H$ și $k$, pentru corect fixat non-maligne $f$. Dacă această posibilitate împiedică totuși o ștampilă de cauciuc să lovească hârtia, am putea folosi $k'=f(d_U,H\oplus j,k)$ Unde $j$ este numărul de invocări anterioare ale $f$ în semnătură.

Notă: când și dacă nu există niciun dezavantaj în a face semnătura deterministă, putem ignora intrarea $k$. Când luăm în considerare unele (dar departe de toate) atacuri laterale care pot fi chiar mai sigure, în special împotriva atacurilor adversarilor care cunosc și controlează $k$.

Andy avatar
drapel pe
În primul rând, mulțumesc mult pentru explicații! Deci, dacă k este de la TRNG (en.wikipedia.org/wiki/Hardware_random_number_generator), Știind cum a fost produs. Mai este posibilă prima mea soluție? care este doar numărul de verificare de biți ai lui k. Să presupunem că k (din TRNG) sunt secrete și aleatoare
fgrieu avatar
drapel ng
@Andy: Am extins modul de bază (dacă nu este recomandat) de a genera $k$ în ECDSA, vezi al treilea paragraf al răspunsului. Rețineți că, dacă utilizați o implementare existentă a semnăturii ECDSA, probabil că generează $k$ (și dacă îi pasă de securitate, ar putea folosi o tehnică similară cu cea pe care o descriu în al patrulea paragraf). Atenție că există multe dificultăți în realizarea unei implementări sigure a generării semnăturii ECDSA (canale secundare, atacuri de eroare..), iar înțelepciunea comună este că aceasta ar trebui lăsată în seama programatorilor de securitate experimentați.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.