înregistrare Logare
Puncte:1
DADi590 avatar Crypto

Siguranța AES-256/CBC/PKCS#7 + randomizarea și reutilizarea IV

drapel es
DADi590

Pentru început, nu sunt în niciun caz un expert sau ceva aproape de asta în criptografie. Știu lucrurile de bază despre asta, suficient pentru a alege mai mult sau mai puțin o metodă de implementat și apoi a citi despre ea, astfel încât să știu ce implementez. Așa că vă rog să vă scuzați orice întrebări presupuse stupide haha.

Având în vedere acest lucru, am creat o clasă de criptare/decriptare AES-256/CBC/PKCS#7 + HMAC-SHA512 într-o aplicație de asistent Android pe care o creez (se presupune că ar avea la nivel local (foarte?) lucruri personale și s-ar putea să-l public pe Play Store, deci nu este doar pentru mine). Se presupune că acea combinație va fi foarte sigură pentru următorii ??(?) ani. S-ar putea să fie puțin mai lent, dar nu mă deranjează, cel puțin deocamdată (foarte puține date). Totuși, am citit și că există o problemă cu aceasta, și anume atunci când vectorul de inițializare este reutilizat. Cu CBC, se pare că nu se pot recupera datele (nu?), așa cum se poate și cu alte moduri, și de aceea am ales-o pe aceasta. [Dacă există alte probleme cu această metodă, mă bucur să aflu despre ele.]

Dar este posibil, după ceva timp, să detectăm modele și să vedeți unde mesajele sunt egale (blocuri egale de 16 octeți). Știind ce înseamnă acel bloc, s-ar putea ști că nu s-a schimbat de-a lungul timpului după diferite versiuni criptate, de exemplu.

Așa că am avut o idee, care este: toate datele pe care le criptez trebuie să fie codificate folosind UTF-7. Valorile de octet rămase (128-255) sunt folosite ca valori aleatorii pentru a fi puse câte câte 16 octeți, într-o poziție aleatorie. De exemplu, în indexul 4 se adaugă un octet de 154, iar în indexul 19 se adaugă un octet de 234. În acest fel, este întotdeauna aleatoriu și, de fapt, blocurile egale în date vor fi diferite dacă același IV este reutilizat ("aleatoriu" poate repeta valori și nu pot verifica dacă le-am folosit deja în acest caz, așa că m-am gândit pe aceasta pentru a preveni probleme).

Este aceasta o abordare bună? Ar putea atenua problema? Poate o rezolvăm complet pentru următorii ani infiniti și metoda ar fi acum complet sigură sau cel puțin mult mai sigură?

De asemenea, dacă ceva din ce am spus este greșit, mă bucur să fiu corectat! Mulțumiri!

93
0 + 0
aes
cbc
Puncte:1
Maarten Bodewes avatar Crypto
drapel in
Maarten Bodewes

Singurul motiv pentru care ar trebui să vă fie frică de reutilizarea IV este dacă generatorul de numere aleatorii este oprit.

Presupunând un IV complet aleatoriu pe care l-ați putea cripta $2^{64}$ blocuri în cadrul AES-CBC și încă mai au doar unul în $~2^{64}$ șansa ca să aibă loc o coliziune (aproximativ). Rețineți că problema introducerii repetate nu se limitează la IV; fiecare text cifrat este folosit ca un „vector” pentru următoarea criptare bloc AES, până la urmă.

Ideea ta este să randomizezi oarecum blocurile de text simplu, pentru a ajuta împotriva coliziunilor IV, ceva care este mai puțin frecvent decât coliziunile din ieșirea AES (presupunând că mesajele sunt mai mari de un bloc). Dar asta nu va ajuta cu adevărat, deoarece o coliziune poate avea loc, iar dacă atacatorul știe ce este în majoritatea textului simplu, va fi ușor de ghicit ce este în celălalt bloc.

Există totuși încă o problemă. Acum se pare că aveți informații aleatorii pentru a efectua randomizarea blocurilor. Dacă ați folosi acele date aleatorii pentru a genera un IV aleatoriu securizat, probabil că nu v-ați întâlni problema în primul rând.

Dacă doriți să vă protejați datele, este mai bine să derivați sau să încapsulați chei specifice mesajelor din „cheia principală”.

Dacă sursa ta de aleatorie nu este sigură criptografic, probabil că oricum ai probleme. Puteți arunca o privire la modul AES-SIV pentru a atenua oarecum problema. În acest mod, IV depinde de mesajul text simplu.

Ceea ce cu siguranță nu ar trebui să faceți este să vă modificați protocolul pentru a încerca să ascundeți deficiențele algoritmilor. Este puțin probabil să reușească și adaugă tot felul de complexitate inutilă. Criptarea AES nu ar trebui să necesite niciun tapdancing, dacă sunt folosite constructele potrivite.

Note de securitate:

  • Pentru a vă proteja împotriva modificărilor viitoare, aș recomanda includerea și IV-ul în calculul MAC. Utilizarea unui MAC peste IV va adăuga doar 16 octeți la calcul, ceea ce este relativ nesemnificativ.În prezent, IV-ul tău nu poate fi schimbat de către un atacator, dar o schimbare a protocolului ar putea face IV-ul și, prin urmare, mesajul tău vulnerabil la schimbare.
  • De asemenea, aș dori să vă avertizez că, dacă datele sunt transmise MAC, sunteți vulnerabil la atacuri de substituție: înlocuirea datelor unui fișier cu altul. Veți avea nevoie de ceva verificabil / unic în antet / metadate și MAC împreună cu textul dvs. cifrat (avem scheme AEAD pentru a vă ajuta cu asta).
0 + 0
DADi590 avatar
drapel es
DADi590
Ei bine, ideea mea a fost că, deoarece foloseam deja un generator aleator securizat (SecureRandom în Java) pentru IV, l-aș putea folosi din nou pentru randomizarea datelor. Deoarece valorile aleatoare se pot repeta, m-am gândit la asta. Și apoi, de asemenea, ceea ce ați spus „fiecare text cifrat este folosit ca „vector” pentru următoarea criptare AES-block-encrypt” ar putea fi, de asemenea, atenuat, deoarece totul a fost practic aleatoriu în fiecare bloc al mesajului, care are 16 octeți (în meu cap de nici un expert haha). Dar nu m-am gândit cât de des s-ar putea întâmpla ciocnirile... Doar dacă „se vor întâmpla, așa că o voi face mai greu”.
0
Răspunde
DADi590 avatar
drapel es
DADi590
Dar dacă există șanse foarte mici de coliziune și ideea mea nu va face atât de mult, o voi elimina și voi reveni la codificarea normală UTF-8. De asemenea, despre AES-SIV, nu pot continua.Nu este implementat în Android (Cipher on Android Developers - mai sus Rezumat în cazul în care sunteți interesat). Partea de încapsulare, dacă am înțeles bine de pe Wikipedia, nu este cazul meu. Nu stochez cheia nicăieri (cel puțin deocamdată - fără server, doar un mic proiect). Este derivat dintr-o parolă care trebuie introdusă manual - acesta este lucrul care trebuie să fie suficient de sigur (mai bine decât stocarea locală a cheii).
0
Răspunde
Maarten Bodewes avatar
drapel in
Maarten Bodewes
Rulați Argon2 sau - dacă doriți să utilizați unul deja implementat - PBKDF2.Atenție că acceptați ASCII doar dacă doriți să rămâneți compatibil cu Java SE și că utilizați un hash care are o dimensiune de ieșire suficient de mare (nu extrageți mai mult decât dimensiunea de ieșire hash din funcție). O sare aleatorie sigură de 16 octeți și un număr de iterații cât mai mare posibil și sunteți gata (s-ar putea să doriți să includeți un număr de versiune în protocolul dvs. în cazul în care doriți vreodată să îl actualizați sau numărul de iterații) . `new SecureRandom()` este, în general, bine și ar trebui să vă ofere un PRNG bine seed.
1
Răspunde
DADi590 avatar
drapel es
DADi590
Despre notele de securitate, includ deja IV-ul în calculul MAC (calculez MAC cu textul cifrat, IV și cheia MAC). De asemenea, folosesc AEAD pentru asta. Am citit exact ce ai spus, că este posibil să schimbi 2 fișiere criptate și oricum vor fi citite. Deși, dacă aș include un antet în interiorul fișierului, s-ar putea să nu funcționeze. Dar, în orice caz, da, voi folosi AAD pentru a ajuta la prevenirea acestui lucru. Multumesc pentru toate informatiile! O voi marca ca răspuns!
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

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.