Cât de nesigură este AES-128-CTR pentru a cripta orice fel de date utilizând formatul de fișier Ethereum keystore?
On noiembrie 18, 2020 by adminFolosesc formatul de fișier Ethereum keystore pentru a cripta orice alte date, cum ar fi un text simplu sau JSON.
Iată un exemplu de pseudocod al implementării:
MY_PASSWORD = "VeryDifficultPasword432131!@!#%" MY_TEXT = "This is my secret text" iv = randomBytes(16) kdfparams = { dklen: 32, n: 262144, r: 1, p: 8, salt: randomBytes(32) } key = scrypt(MY_PASSWORD, kdfparams) ciphertext = encryptCipheriv("aes-128-ctr", MY_TEXT, key, iv) mac = sha3(key[16:32], ciphertext)
Cu acest cod pot genera fișierul keystore care arată astfel:
{ "crypto" : { "cipher" : "aes-128-ctr", "cipherparams" : { "iv" : "83dbcc02d8ccb40e466191a123791e0e" }, "ciphertext" : "d172bf743a674da9cdad04534d56926ef8358534d458fffccd4e6ad2fbde479c", "kdf" : "scrypt", "kdfparams" : { "dklen" : 32, "n" : 262144, "r" : 1, "p" : 8, "salt" : "ab0c7876052600dd703518d6fc3fe8984592145b591fc8fb5c6d43190334ba19" }, "mac": "102aedfe8c308c735a76295f9908d9b7de40fb1c07f2f71e05de7a0b2f323a12" } }
Acesta este fișierul standard care stochează milioane de dolari de persoane în Ethers.
Întrebări:
- Este sigur?
- Dacă nu, de ce?
- Dacă da, este, de asemenea, criptarea sigură a textului simplu sau JSON (fără format hexazecimal)?
- Este sigur să setați un
kdfparams.n
?
Edit: Pentru a clarifica de ce întreb acest lucru se datorează faptului că o altă persoană a spus acest lucru:
Acest lucru nu este deloc sigur. Această implementare conține multe erori de bază. Un exemplu este utilizarea unui generator de numere aleatorii nesigure, care distruge complet securitatea criptării. Un altul este utilizarea AES 128-CTR fără autentificare.
Comentarii
- Mai întâi, definiți ” securizat ” . Dar prin orice definiție rezonabilă a acestuia, cu o parolă în aceeași ligă ca ‘ 1234 ‘ și text clar că mare și redundant, nimic utilizabil nu este sigur.
- Sigur în termeni de foarte foarte greu de rupt chiar dacă este un bun criptograf. L et me edit pentru a clarifica că ar fi o parolă foarte puternică.
- Acum, definiți ” break ” . Găsiți parola originală? Ghiciți textul clar dintr-un text cifrat? Ghiciți o parte din textul clar din multe coduri de text partajate pe care unele? Ghiciți un text clar din multe texte criptate și din celălalt text clar? Putem obține ajutor de la un executabil care rulează pe aceeași mașină (și dacă da, exact ce procesor cu ce patch de microcod? Se folosește AES-NI?). Putem folosi EMI ca canal lateral? Un keylogger, hardware sau sotfare? Într-adevăr, ce ‘ este implementarea randomBytes, care are o influență?
- Nu puteți răspunde la această întrebare uitându-vă la psuedocode. Implementarea efectivă poate conține tot felul de vulnerabilități și canale laterale . De asemenea, securitatea nu este binară, este ‘ o chestiune despre cât de departe sunteți ‘ dispus să mergeți pentru a vă proteja împotriva tot mai mult = „ab2b2425ad”>
atacuri exotice .
Răspuns
Cel mai rău slăbiciunea pur criptografică este parola (1). Cele mai grave (și mult mai grave) puncte slabe practice sunt probabil în implementare (6) (7) și cele (4) (5) pe care criptografii le resping ca în afara domeniului de criptare (întrebarea este singurul obiectiv declarat).
Candidații pentru puncte slabe, de la criptografice (dar încă de luat în considerare) până la implementare:
- Parola: este greu să ne amintim o parolă cu peste 48 de biți de entropie ( că „echivalează cu un număr din 16 cifre, cum ar fi 3141592653589793 sau 2718281828459045 și mai mult decât prevede de XKCD ). Folosind N = 262144 = 2 18 , r = 1, p = 8 = 2 3 , cumpără cel puțin 18 + 3 + 1 = 22 biți (vezi this ) în comparație cu un hash SHA-256 drept urmat de AES-128, cred că cu 32 de biți mai puternic, astfel cheia ar putea fi de 80 de biți bună, ceea ce este nu este complet ruptibil prin forță brută, dar încă destul de sigur.
- AES-128: acesta are o cheie de 128 de biți, nu se cunoaște pur criptanalitic atacă mai bine decât forța brută și, prin urmare, este mult mai bun decât parola.
- Modul CTR: cu blocul de 128 de biți al AES, singurul mod în care reutilizarea fluxului de taste ar putea fi introdus ar fi un număr aleatoriu rău generator pentru IV (vezi 6)
- Dimensiunea textului simplu poate fi dedusă fără efort din dimensiunea textului cifrat. Acesta este în mod explicit nu o slăbiciune teoretică a criptării, deoarece lungimea este exclus din ceea ce un cifru ar trebui să ascundă despre textul clar. Totuși, acesta poate fi o slăbiciune practică. Spunem că analiza textului cifrat concluzionează că este 17267095423 octeți; și există, undeva în procuratură, prezintă un dosar cu dimensiunea exactă, care demonstrează în mod evident căutarea și confiscarea textului cifrat și care simpla reținere este ilegală.
- Lipsa de detectare a modificărilor (intenționate sau accidentale) ale textului cifrat, corespunzătoare modificării previzibile în textul clar: din nou, aceasta este în mod explicit nu o slăbiciune teoretică a criptării, dar poate permite anumite atacuri dacă adversarul poate modifica textul cifrat (exemplu: dacă textul în clar este un executabil sau PDF cu o fracție cunoscută, acest lucru poate permite schimbarea a ceea ce face executabilul în legătură cu orice sau poate afișa PDF-ul ca despre orice). Criptare autentificată ( AES-GCM ..) rezolvă acest lucru.
- Generator de numere aleatorii: dacă acest lucru este rău sau mai rău se blochează mai mult sau mai puțin (obligatoriu XKCD și Dilbert care se transformă în realitate prea des), ceea ce ar permite recuperarea textului simplu în multe scenarii, inclusiv codificarea în mod repetat a diferitelor texte în engleză sau adrese de e-mail cu aceeași parolă.
- Un canal lateral, care este în general vorbind despre scurgeri neprevăzute sau neatinse de informații în contextul implementării sau al utilizării. Există atât de multe:
- Recuperarea parolei de la titularul parolei prin exploatarea unui defect procedural (parolă pe o notă postit, listă de parole principale), criptanaliză a furtunului de cauciuc (obligatoriu XKCD ), variante legale (care implică utilizarea expresiilor în tonul disprețului instanței ), luare de mită, impregnare chimică ..
- Recuperarea parolei de către surfing pe umăr , key logger (software sau hardware), cameră, microfon (o captură audio bună de sunetul tastelor la introducerea unei parole scurge multe informații despre parolă, mai ales atunci când este corelat cu introducerea tastaturii cunoscute de același operator în aceleași condiții) ..
- Compromis direct al textului clar așa cum se arată pe ecran (cu TEMPEST variante ale acestuia), tipărite, în timp ce sunt transmise către o imprimantă sau accesate de la distanță de o rețea, sau doar stocate „temporar” ..
- Compromis direct al sistemului de operare al mach faceți criptare sau decriptare (obținerea accesului temporar la root este suficientă, înseamnă că în 7.7 sunt jocuri pentru atacator).
- Canal lateral criptanalitic la distanță, inclusiv DPA și varianta electromagnetică DEMA și ipotetic calendar dacă aparatul care efectuează criptarea / decriptarea este accesat de o rețea și nu utilizează instrucțiuni AES .
- Canal lateral criptanalitic dintr-un proces care rulează pe același hardware (inclusiv o altă mașină virtuală), inclusiv direcționarea bazată pe cache pentru AES atunci când nu se utilizează AES instrucțiuni sau instrucțiuni mai generale (Meltdown, Spectre) care sunt la moda în zilele noastre.
- Exploatarea diferitelor bug-uri software; asta este uriaș.
Comentarii
- Ar fi mai util dacă am hash parola înainte de criptare? Ca și cum ar fi folosirea sha sau md5?
key = scrypt(sha(MY_PASSWORD), kdfparams)
- @EnZo: Hashing parola înainte de introducerea în scrypt nu schimbă prea mult dificultatea de atac a parolei ( punctul 1). Pentru a îmbunătăți acest lucru, aveți nevoie de o parolă mai bună, de o parametrizare mai bună pentru criptare sau de o schemă mai bună de derivare a cheilor bazată pe parolă (Argon? Balon?)
Răspuns
Principalul element de securitate care poate fi atacat în schema de mai sus este – desigur – fraza de trecere. Acum sarea este importantă pentru a evita atacurile la masă curcubeu, dar în caz contrar nu adaugă atât de multă securitate. Dacă sarea și parola sunt în mod rezonabil unice, atunci cheia este unică, de asemenea. În acest caz, IV nu este atât important.
Deci, deși utilizarea unui generator de numere aleatorii nesigur este rău, probabil că nu va avea o influență atât de mare asupra securității practice. Cu toate acestea, , indică faptul că practicile rele au fost într-adevăr implementate. Ce se întâmplă dacă fraza de acces a fost generată folosind același generator aleatoriu nesigur? Ce se întâmplă dacă apar alte erori de implementare?
Utilizarea textului cifrat non-autentificat este mai mult o problemă, deoarece ar permite adversarului să schimbe textul clar pentru fiecare bit. Adversarul poate inversa pur și simplu orice bit de text cifrat și bitul de text clar în aceeași poziție va fi răsturnat. Acest lucru ar însemna că ați avea o eroare sau o problemă atunci când utilizați portofelul. Confidențialitatea conținutului portofelului nu este probabil pierdută, dar utilizarea criptării autentificate este cu siguranță cea mai bună practică.
Comentarii
- Vă mulțumim! Ați putea explica abia cum să obțin text criptat autentificat cu acest mod? Voi edita Exemplele de mai sus, deoarece cred că sunt în legătură cu proprietatea originală Mac pe care am eliminat-o din fișierul original de depozitare de chei.
- Modul CTR este modul de bază al CCM, GCM, EAX, SIV și o grămadă de alte tipuri autentificate cifrări. Cu toate acestea, o combinație a modului CTR cu un MAC (H) poate fi, de asemenea, sigură.Ambele produc o etichetă de autentificare cu aproximativ aceeași dimensiune / securitate. CCM și EAX sunt puțin mai mult decât combinații specifice de CTR și un MAC unde aceeași cheie poate fi utilizată pentru cifrare și MAC.
- Rețineți că I ‘ ve am răspuns la această întrebare pe cât am putut, folosind cunoștințe generice despre cifre (nu atât de mult Ethereum). Ella Rose are dreptate că nu putem concluziona securitatea sistemului din informațiile oferite în întrebare. Așa că m-am concentrat ‘ exclusiv pe utilizarea CTR.
- Ei bine, aleatoare pare să se bazeze – în cele din urmă – pe sistemul aleatoriu. Adesea sursele aleatorii ale sistemului sunt relativ sigure, iar termenul CSPRNG este într-adevăr menționat de sursă. Deci, afirmația că nu este aleatorie este greșită, cu excepția cazului în care sistemul aleatoriu nu este bine implementat sau însămânțat.
- Nu este recomandată crearea unui MAC direct din SHA-3, KMAC ar fi trebuit să fie folosit (probabil pur și simplu nu a fost ‘ încă specificat în acel moment). Dar nu mă pot gândi la nicio situație în care utilizarea peste concatenarea cheii și a textului cifrat ar pune vreodată o problemă.
Lasă un răspuns