Puncte:0

Necesitatea PBKDF2 în configurarea curentă?

drapel ie

Am o singură parolă, care este de octeți aleatori, care criptează o bază de date. Momentan folosesc o schemă de criptare de https://gist.github.com/jbtule/4336842. Pentru a rezuma, luăm singura noastră parolă, generăm o sare pentru o cheie de autentificare și o cheie de criptare, rulăm PBKDF2 cu 10.000 de iterații pentru a genera cheile, apoi folosim AES pentru criptare și HMAC pentru autentificare. Sărurile sunt apoi depozitate lângă textul cifrat.

Problema mea este că generația cheie devine prohibitiv de lentă. Criptarea și decriptarea au loc împreună cu alte proceduri grele ale procesorului și multe interogări și, prin urmare, multe decriptări, au loc pentru orice procedură dată. Uneori, pasul de generare a cheii poate dura ~5 secunde pentru fiecare element pe care vreau să-l decriptez.Dar, pe măsură ce citesc despre asta, se pare că funcțiile de derivare a cheilor nu sunt necesare pentru cazul meu de utilizare, deoarece parola originală este total aleatorie.

Mă gândesc să iau parola unică și să o concatenez cu săruri de criptare și auth înainte de criptarea/decriptarea AES și HMAC. De asemenea, aș putea reduce pur și simplu iterațiile PBKDF2 la ceva scăzut, cum ar fi ~ 10, care ar putea părea neglijent, dar ar implica schimbarea mai puțin cod și mai puține teste. Există o vulnerabilitate de securitate care îmi lipsește aici? Oricare dintre aceste soluții m-ar deschide către un atac, cu forță brută sau altfel? Din ceea ce citesc despre generarea cheilor, se pare că nu am nevoie de ea, dar soluțiile homebrew sunt întotdeauna proaste, așa că sunt foarte precaut în eliminarea oricărei securități pe care o avem. Multumesc pentru ajutor.

Swashbuckler avatar
drapel mc
Atâta timp cât parola are cel puțin lungimea unei chei și este *cu adevărat* aleatorie (generată de un generator de numere aleatoare criptografice), atunci nu trebuie să utilizați PBKDF2. Dacă ambele nu sunt adevărate, puteți utiliza în continuare PBKDF2 și pur și simplu reduceți numărul de iterații dacă într-adevăr cauzează o problemă de performanță.
SAI Peregrinus avatar
drapel si
Rețineți că cheile aleatoare adevărate pot conține caractere NULL încorporate (0x00), în timp ce parolele sunt șiruri de caractere (de obicei UTF-8) și, prin urmare, nu pot conține NULL încorporate (și, de obicei, nu pot conține alte caractere neprintabile) și, prin urmare, au mai puține entropie decât ar indica lungimea lor. Un PBKDF preia o parolă ca șir și emite o secvență de octeți. Deci, chiar dacă generați „parola” cu un CSPRNG, ați dori totuși să utilizați un KDF pentru a-l converti din caractere „printabile” într-o cheie.
Swashbuckler avatar
drapel mc
@SAIPeregrinus Da, am văzut câteva probleme de interoperabilitate în care o implementare ar putea gestiona valorile nule, dar alta nu.
Puncte:1
drapel ng

Ori de câte ori PBKDF2 este utilizat ca un KDF cu o cheie de entropie mare, parametrul său de iterație poate fi în siguranță 1, ceea ce ar trebui să îmbunătățească considerabil problema la îndemână cu puțină muncă. Acest lucru se aplică dacă cheia este o parolă care are cel puțin 128 de biți entropie (de exemplu, 22 de caractere selectate aleatoriu dintre 64).

Dacă, pe de altă parte, parola este suficient de simplă pentru a fi memorată, sau introdusă convenabil, sau aleasă de un utilizator cu puțină motivație sau judecată insuficientă pentru a folosi o parolă bună, atunci este nevoie de un fel de întinderea cheii, așa cum oferă PBKDF2. Cu toate acestea, PBKDF2 este o metodă extrem de slabă de întindere a cheii. Iterația 10.000 PBKDF2 este aproape transparentă pentru un atacator care folosește ASIC și un obstacol de depășit pentru cel care folosește GPU. Aș sfătui să treceți la ceva mai bun (care implică memorie): Argon2, scrypt, chiar și cel mai mic bcrypt, cât mai curând posibil, pentru partea care întinde parola. Și chiar dacă faci asta, ai nevoie de o opțiune mai bună decât să o faci atât de des încât devine un blocaj.

Cea mai generală metodă este stocarea în cache. Este în întregime în regulă temeinic entropy-întinde parola doar o dată la pseudo-entropie de 128 de biți, scrie-o de-a lungul parolei (fie ea în RAM sau orice altceva, atâta timp cât condițiile de acces nu sunt mai îngăduitoare decât pentru parola în sine), apoi folosește-o în loc de parola fără întindere suplimentară (doar derivări, pe care le poate face PBKDF2).

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.