Puncte:2

Cât de mai puțin siguri erau acei octeți aleatori?

drapel kn

În baza noastră de cod Python, au fost generați niște octeți aleatori pe care doream să fim siguri din punct de vedere criptografic. Anterior, codul era:

capabilitate = "".join(secrets.choice(string.digits) for i in range(33))

L-am schimbat in:

capabilitate = secrets.token_bytes(16)

După estimarea mea, prima versiune a ales de 33 de ori între 10 cifre și astfel avea 33*log2(10)=110 biți de entropie, în timp ce al doilea are 128 de biți de entropie. Este corect acest calcul?

poncho avatar
drapel my
„Cât de mai puțin siguri erau acei octeți aleatori”; depinde și de ce ai făcut cu acești octeți. De exemplu, dacă le-ați folosit ca cheie AES-128, ei bine, asta înseamnă că cel mai probabil ați folosit doar primii 16 octeți ai primului exemplu, ceea ce este *semnificativ* mai rău decât „securitate pe 110 biți”
Maarten Bodewes avatar
drapel in
Sunt de acord cu Poncho. Nu văd nimic în neregulă cu calculele dvs., dar depinde de modul în care sunt utilizate cifrele (și luând în considerare metoda de generare a acestora, aceasta poate fi orice modalitate bună sau proastă). O dată lucru este, de asemenea, că, dacă acesta este considerat un număr, s-ar putea ajunge cu câteva zerouri la început, care pot fi eliminate înainte ca valoarea să fie folosită. Depinde din nou de cod după aceea dacă are un impact semnificativ sau nu.
Maarten Bodewes avatar
drapel in
Atenție la tiparea Duck folosită în Python. A avea un șir format din cifre sau octeți este destul de diferit. Nu-mi place să folosesc șiruri pentru valori binare; dacă aș proiecta un API, aș accepta doar [`bytes` sau `bytearray`](https://www.w3resource.com/python/python-bytes.php) pentru Python 3
drapel kn
Folosim totul pentru a crea o adresă URL de neghicit (cu base64).
Puncte:3
drapel us

Matematica ta sunt corecte, teoretic. Într-adevăr, utilizarea cifrelor imprimabile pentru a stoca aleatoriu este un compromis între stocare și lizibilitate. Cu toate acestea, din moment ce vorbiți despre securitatea criptografică, vreau să menționez ceva.

Când luați în considerare aleatoriu, există două lucruri pe care ar trebui să le aveți în vedere: imprevizibilitatea și uniformitatea.

  • Nu este cazul dvs., dar dacă utilizați încorporate Python, cum ar fi Aleatoriu, ai uniformitate dar nu imprevizibilitate, pentru ca foloseste un PRNG. Deci, vorbind criptografic, conform legilor lui Kerchoff, obțineți 0 entropie.
  • Dacă utilizați secrete. Folosește (în Linux de exemplu) /dev/urandom care este în general considerat sigur din punct de vedere criptografic *, cu excepția cazului în care (de exemplu, în timpul pornirii) obțineți un estimat cantitatea de entropie (nu o puteți măsura de fapt) care sperați că este puțin mai mică decât cea teoretică.

* Există/a existat o dezbatere în curs privind utilizarea /dev/urandom sau /dev/random. Puteți citi mai multe Aici și puteți verifica, de asemenea, comentariul SAI Peregrinus mai jos.

Paul Uszak avatar
drapel cn
Ei bine, ce vrei să spui _"folosirea cifrelor imprimabile pentru a stoca aleatoriu este un compromis între stocare și lizibilitate"_? Sunteți preocupat de capacitatea de stocare?
SAI Peregrinus avatar
drapel si
Acea „dezbatere în curs” nu mai este o dezbatere de ceva vreme. Nucleele Linux actuale nu au *nicio* diferență de comportament între /dev/random și /dev/urandom. Se blochează la pornire până când piscina este însămânțată, apoi nu se blochează după aceea.

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.