Puncte:0

Cât de sigur este AES 256bitkey generat de la PBKDF2

drapel cn

Folosesc criptarea CryptoJS AES 256:

CryptoJS.AES.encrypt(realData, generateKey(fraza de acces), {iv: iv});

Secretul este generat prin:

funcția generateKey(frază de acces) {
  const salt = CryptoJS.lib.WordArray.random(128 / 8);
  const key256Bits = CryptoJS.PBKDF2(frază de acces, sare, {
    Dimensiune cheie: 256 / 32,
    iterații: randomNumber,
  });

  cheie return256Bits;
}

Sunt nou în acest sens și mă întreb cât de sigur sunt cei 256 de biți de taste de mai sus?

Poate cineva să folosească forța brută pentru a afla șirurile de codificare hex, base64 ale celor 256 de biți de cheie, iv fără să-i pese de fraza de acces.

Apoi convertiți cei 256 de biți de cheie reali, iv care decriptau datele reale în criptarea AES? Sau cei 256 de biți de cheie pot fi forța brută?

Mulțumiri!

Puncte:1
drapel ng

Valoarea pentru iterații: randomNumber nu trebuie să fie un număr aleatoriu. Este un număr de iterații care controlează costul PBKDF2. Ar trebui să fie setat cât mai sus este tolerabil în aplicație, iar protecția oferită de PBKDF2 împotriva căutării prin parole crește aproximativ liniar cu acel parametru. În cele ce urmează îmi asum un mare iterații (să zicem o linie de bază de o sută de mii) și asta sare se depozitează cumva. Presupun, de asemenea, că este folosit HMAC-SHA-1 (prestabilit) sau HMAC-SHA-256 (de asemenea comun).

Din câte știm, principala slăbiciune în ceea ce este descris este că este posibil să se testeze o frază de acces, rulând generateKey și apoi testând cheia corespunzătoare folosind o criptogramă AES cunoscută. Este asta „fără să-i pese de expresia de acces”? Asta nu-mi este clar.

Problema este că PBKDF2 poate fi rulat la viteză foarte mare de către atacatori care folosesc GPU-uri, FPGA-uri sau ASIC-uri. Când iterații este mare (cum ar trebui), PBKDF2 este blocajul generateKey și căutare prin parolă. Deci, adversarii pot căuta parole mai repede decât utilizatorii obișnuiți folosind CryptoJS. Din punctul de vedere al îngreunării căutării prin parole, care este scopul principal al întrebării, PBKDF2 este, prin urmare, printre cele mai proaste utilizări posibile a puterii CPU de rezervă pentru întinderea cheii când vine vorba de adversari puternici. Opțiuni mult mai bune ar Argon2, scrypt sau chiar bcrypt.

Tu decizi dacă este o coincidență că NIST recomandat anterior PBKDF2, și încă nu impune folosirea a ceva mai bun; cum a fost împins înainte Dual_EC_DRBG, cu intenția evidentă de a permite informațiilor americane să spargă această cripto. S-ar putea să se aplice aparatul de ras al lui Hanlon, dar îi țin pe oamenii de știință de la NIST la o mare stima.

Kim Mỹ avatar
drapel cn
„fără să-i pese de expresia de acces”? Adică, faza de acces transmisă în generateKey (fraza de acces) ar putea conține caractere speciale pentru a o face puternică pentru forța brută. În timp ce cheia a revenit de la generateKey(fraza de acces), pe care o pot folosi pentru a cripta și decripta datele reale în CryptoJS.AES.encrypt(realData, generateKey(fraza de acces), {iv: iv}) este o matrice de octeți. Deoarece octeții sunt noi pentru mine, așa că nu știu dacă este greu de focalizat și repus la decriptare ca cheie.
Kim Mỹ avatar
drapel cn
De asemenea, șirul de codificare care poate fi citit (Hex, Base64) al generateKey(fraza de acces) (pe care în Crypto-JS îl pot folosi doar key256Bits.toString()) nu conține caractere speciale dacă hex sau numai „/,+” și sfârșitul ciudat „ ==' dacă baza64. Și asta este ușor pentru forța brută, apoi convertiți înapoi în matrice de octeți (cheia returnată de la generateKey (fraza de acces)), apoi pusă în decriptarea realData? Scuze, este nou pentru mine și corectează-mă dacă greșesc. Mulțumiri!
Kim Mỹ avatar
drapel cn
în biblioteca Crypto-JS, cu condiția șirului de codificare care poate fi citit (Hex, Base64) al generateKey (fraza de acces), pot folosi doar CryptoJS.enc.Hex.parse() pentru a obține 256 de biți de cheie reali și pentru a decripta datele reale fără nici măcar să-mi pese de fraza de acces transmis în generateKey(fraza de acces) pentru a genera cheia de decriptare?
fgrieu avatar
drapel ng
Nu este mai ușor să forțați o cheie de 256 de biți exprimată ca șir Base64 de 43 de caractere decât să forțați echivalentul brut de 32 de biți. Și asta este practic imposibil. Codificarea corectă a ieșirii lui PBKDF2 pentru a face o cheie AES cu toți cei 256 de biți este un detaliu important. Am presupus că nu are dreptate. Aceasta este o problemă de programare, foarte dependentă de CryptoJS, deci mai degrabă în afara subiectului. nu am discutat.
dave_thompson_085 avatar
drapel cn
(@KimMỹ+) crypto-js.PBKDF2 returnează un _WordArray_ care este un tip de „obiect” javascript care _conține_ octeți (dar nu este, de exemplu, Unit8Array încorporat în javascript); dacă îl convertiți într-un șir (de ex.de console.log) acel rezultat este codificat în base64, dar dacă îl transmiteți ca cheie unei instanțe crypto-js.Cipher care folosește octeții din ea, în timp ce dacă treceți un _string_ (încorporat) unei astfel de instanțe, se aplică un PBKDF definit de OpenSSL și destul de slab (EVP_BytesToKey cu niter=1) și, de asemenea, folosește în mod implicit formatul definit de OpenSSL cu `Salted__`+8bytes prefixați textului cifrat și codificat în base64.

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.