Lasă Partajarea secretelor lui Shamir (SSS) este construit din câmpul finit $K = \mathbb F_{p^m}$, adică $K$ este o extensie de câmp finit cu $p^m$ elemente, $comanda(K) = p^m$.
Când un atacator accesează $k-1$ al $k$ acțiunile SSS, restul de toate valorile din $K$ au aceeași probabilitate de a fi candidat al ultimei cote. Acest lucru se datorează proprietății SSS; are o schemă perfectă de partajare a secretelor (adică are secretul perfect ). Prin urmare; atacatorul nu învață nimic decât dacă deține toate acțiunile.
Atacatorul, în timp ce ținea $k-1$ acțiuni, are $p^m$ candidați posibili egali pentru ultima cotă. Singura posibilitate pentru ei este să încerce pe toți să se distingă de cel real, nimic mai mult.
Ei bine, în loc să plătești (sau să furi) pentru $k-1$ acțiunile pot încerca pur și simplu toate $p^m$ elemente ale domeniului. Pentru că;
- Nu au niciun avantaj să aibă $k-1$ acțiuni sau $1$ acțiuni Sunt toți la fel, SSS are un secret perfect.
Acum, deoarece parola este construită din secretul partajat, atunci există o limită pentru un număr posibil de parole; $p^m$. Presupunând că este utilizată o metodă de hashing a parolei proastă, cum ar fi doar SHA-256 pur, atunci dimensiunea câmpului trebuie să fie mai mare decât $2^{93}$ deoarece minerii Bitcoin pot atinge această sumă de SHA-256D într-un an. Prin urmare, este indicat să aveți un câmp cu o comandă mai mare decât $2^{128}$.
Este nevoie de un algoritm de hashing a parolei mai bun, cum ar fi Argon2id, pentru a limita capacitățile atacatorului. De exemplu, dacă utilizați PBKDF2 cu un număr de iterații egal cu 1M (Argon2 are și iterație), atunci reduceți căutarea atacatorului cu $\aproximativ 2^{20}$. Dacă utilizați memoria-hard și numărul de fire care acceptă funcții de hashing a parolelor precum Argon2, atunci reduceți capacitățile de paralelizare ale atacatorului, în special în cazurile ASIC/GPU. Decideți-vă riscurile și vizați securitatea, apoi ajustați parametrii funcțiilor hash de parole. Și nu uitați să adăugați o sare aleatorie la hashingul parolei.
Dacă se folosește și cota pentru a crea o cheie de criptare, cota trebuie să fie egală sau mai mare decât dimensiunea cheii. Motivul simplu este acesta nu se poate crește entropia prin hashing.
Este posibil ca atacatorul să poată face forță brută și să găsească parola, având în vedere că există o modalitate de a verifica dacă o parolă ghicită este corectă sau nu (cum ar fi utilizarea unei autentificări pe un site web de mai multe ori până când intri)?
Ei bine, majoritatea site-urilor/sistemelor bune protejează împotriva acestor atacuri limitând încercările de parole sau având autentificare în doi factori. Cu toate acestea, putem presupune că atacatorul accesează DB pentru a obține hash-ul parolei (parolelor). Acesta este modelul obișnuit de atac în securitatea parolelor. Deci, măriți ordinea câmpurilor.
Face comanda $n$ a materiei câmpului finit într-un astfel de atac cu forță brută? Va crește valoarea $n$ oferi o securitate suplimentară într-un astfel de scenariu?
Da și da ca mai sus.
