Criptare AES – Cheie versus IV (Programare, Criptare, Aes)

Peter a intrebat.

Aplicația la care lucrez permite utilizatorului să cripteze fișiere. Fișierele pot fi de orice format (foaie de calcul, document, prezentare etc.).

Pentru fișierul de intrare specificat, creez două fișiere de ieșire – un fișier de date criptate și un fișier cheie. Aveți nevoie de aceste două fișiere pentru a obține datele originale. Fișierul cheie trebuie să funcționeze numai pe fișierul de date corespunzător. Nu trebuie să funcționeze pe niciun alt fișier, nici de la același utilizator, nici de la un alt utilizator.

Algoritmul AES necesită doi parametri diferiți pentru criptare, o cheie și un vector de inițializare (IV).

Văd trei opțiuni pentru crearea fișierului cheie:

  1. Încorporarea unui IV codificat în aplicație și salvarea cheii în fișierul cu chei.
  2. Integrați cheia codificată în aplicație și salvați IV în fișierul cheie.
  3. Salvarea atât a cheii, cât și a IV în fișierul cheie.

Rețineți că este vorba de aceeași aplicație care este utilizată de clienți diferiți.

Se pare că toate cele trei opțiuni ar atinge același obiectiv final. Cu toate acestea, aș dori să primesc feedback-ul dumneavoastră cu privire la care ar trebui să fie abordarea corectă.

4 răspunsuri
Cozi

După cum puteți vedea din celelalte răspunsuri, este esențial să aveți un IV unic pentru fiecare fișier criptat, dar de ce?

În primul rând – haideți să trecem în revistă de ce este important un IV unic per fișier criptat. (Wikipedia despre IV). IV adaugă aleatoritate la începutul procesului de criptare. Atunci când folosim un mod de criptare în bloc înlănțuit (în care un bloc de date criptate încorporează blocul anterior de date criptate) rămânem cu o problemă în ceea ce privește primul bloc, care este locul unde intervine IV.

Dacă nu ați avea niciun IV și ați utiliza criptarea în bloc înlănțuită doar cu cheia dumneavoastră, două fișiere care încep cu text identic vor produce primele blocuri identice. Dacă fișierele de intrare s-au schimbat la jumătatea drumului, atunci cele două fișiere criptate ar începe să arate diferit începând din acel moment și până la sfârșitul fișierului criptat. Dacă cineva ar observa asemănarea de la început și ar ști cu ce a început unul dintre fișiere, ar putea deduce cu ce a început celălalt fișier. Știind cu ce a început fișierul în clar și care este textul cifrat corespunzător, persoana respectivă ar putea determina cheia și apoi decripta întregul fișier.

Acum adăugați IV – dacă fiecare fișier ar folosi un IV aleatoriu, primul lor bloc ar fi diferit. Scenariul de mai sus a fost dejucat.

Acum, ce se întâmplă dacă IV-ul ar fi același pentru fiecare fișier? Ei bine, avem din nou scenariul problemă. Primul bloc din fiecare fișier va fi criptat cu același rezultat. Practic, acest lucru nu este diferit de a nu folosi deloc IV-ul.

Să trecem acum la opțiunile propuse:

Opțiunea 1. Încorporați IV codificat în aplicație și salvați cheia în fișierul cheie.

Opțiunea 2. Introduceți cheia codificată în aplicație și salvați IV în fișierul cheie.

Aceste opțiuni sunt aproape identice. Dacă două fișiere care încep cu același text produc fișiere criptate care încep cu un text cifrat identic, sunteți terminat. Acest lucru s-ar întâmpla în ambele opțiuni. (Presupunând că există o singură cheie principală utilizată pentru criptarea tuturor fișierelor).

Opțiunea 3. Salvați atât cheia, cât și IV în fișierul cheie.

Dacă folosiți un aleatoriu IV aleatoriu pentru fiecare fișier cheie, sunteți în regulă. Nu vor exista două fișiere cheie identice, iar fiecare fișier criptat trebuie să aibă propriul fișier cheie. Un fișier cheie diferit nu va funcționa.

PS: Odată ce alegeți opțiunea 3 și IV aleatorii, începeți să căutați cum veți determina dacă decriptarea a fost un succes. Luați un fișier cheie de la un fișier și încercați să-l utilizați pentru a decripta un alt fișier de criptare. S-ar putea să descoperiți că decriptarea se desfășoară și produce în rezultate de gunoi. Dacă se întâmplă acest lucru, începeți cercetările în criptarea autentificată.

Comentarii

  • IV este necesar pentru decriptare. –  > Por Cozi.
  • Cu toate acestea, (cel puțin în modul CBC) un IV greșit va corupe doar primul bloc, putând fi decriptat în continuare restul conținutului fișierului. –  > Por MV..
  • Văd comentarii similare cu cele de mai sus în câteva locuri aici („un IV greșit va corupe doar primul bloc, puteți decripta în continuare conținutul rămas al fișierului”). Acest lucru nu este adevărat. Deoarece primul bloc criptat este IV pentru al doilea bloc (și așa mai departe), un IV necunoscut înseamnă că niciun bloc nu poate fi decriptat. Diagrama CBC de pe Wikipedia arată acest lucru destul de clar: link –  > Por Rich.
  • @Rich – Știu că comentariul meu a întârziat 4 ani, dar… Am încercat să folosesc un IV corupt pentru a decripta folosind bibliotecile AES .NET. Doar primul bloc a fost corupt. Acest lucru se datorează faptului că, blocul criptat este IV-ul următorului bloc în CBC… Iar atunci când decriptați un alt bloc decât primul, aveți întotdeauna blocul anterior criptat. –  > Por Les.
  • @Les – Poate cu 4 ani întârziere, dar ai perfectă dreptate. Comentariul meu de mai sus este complet greșit pentru CBC. Habar nu am la ce mă gândeam. Mulțumesc. –  > Por Rich.
bdonlan

Lucrul important la o perfuzie este nu trebuie să folosiți niciodată același IV pentru două mesaje.. Orice altceva este secundar – dacă poți asigura unicitatea, caracterul aleatoriu este mai puțin important (dar este totuși un lucru foarte bun!). Nu este necesar ca IV să fie (și, într-adevăr, în modul CBC nu poate fi fi) secret.

Ca atare, nu ar trebui să salvați IV alături de cheie – acest lucru ar însemna că utilizați același IV pentru fiecare mesaj, ceea ce contrazice scopul existenței unui IV. În mod normal, pur și simplu ar trebui să adăugați IV la criptat criptat, în clar.

Dacă aveți de gând să vă dezvoltați propriile moduri de criptare, vă rugăm să citiți standardele relevante. NIST are un document bun despre modurile de cifrare aici: http://dx.doi.org/10.6028/NIST.SP.800-38A Generarea IV este documentată în apendicele C. Criptografia este o artă subtilă. Nu vă lăsați tentat să creați variații ale modurilor normale de cifrare; în 99% din cazuri veți crea ceva care arată mai sigur, dar este de fapt mai puțin sigur.

Comentarii

  • @Peter, nu la asta servește un IV. În special, dacă IV este necunoscută, dar cheia este cunoscută, în modul CBC hackerul nu va putea recupera primul bloc de text în clar. Cu toate acestea, va putea recupera restul textului în clar. Singurul scop al IV este de a perturba fișierul astfel încât criptarea repetată să nu producă același rezultat (astfel, atacatorul nu poate spune că două fișiere au același conținut dacă vede că textul cifrat este același). –  > Por bdonlan.
  • Edit: Mi-am șters comentariile anterioare. Sunt de acord, citind I cwe.mitre.org/data/definitions/329.html indică faptul că ar trebui să folosiți un IV aleatoriu și să nu îl reutilizați. Bazându-l pe parolă, sare, etc. ar încălca acest lucru. –  > Por Phil Bolduc.
  • Ar avea sens să folosiți un IV static dacă îl utilizați doar pentru a cripta date aleatorii (chei de sesiune sau alte chei derivate). În caz contrar, ar trebui să folosiți un IV randomizat, iar dacă aveți spațiu pentru <blocksize> bytes suplimentari pentru fiecare mesaj criptat, ați putea la fel de bine să folosiți unul tot timpul. –  > Por Maarten Bodewes.
  • @owlstead, dacă utilizați un IV fix, este esențial să vă asigurați că primul bloc de text în clar al mesajului este întotdeauna unic. Nu este suficient ca mesajul în ansamblu să fie unic. În plus, dacă mesajul dvs. are dimensiunea unui singur bloc de text în clar (de exemplu, chei derivate) și este unic, puteți utiliza pur și simplu modul ECB. –  > Por bdonlan.
  • IV are un scop diferit în funcție de modul de operare utilizat. În CTR, acesta trebuie să fie unic pentru a preveni un pad multiplu. În CBC, acesta trebuie să fie imprevizibil și să nu fie unic. Un contor de mesaje este unic și ar fi OK pentru modul CTR, dar ar fi rău pentru modul CBC. –  > Por Artjom B..
gpeche

Atunci când folosiți un IV, cel mai important lucru este ca acesta să fie cât mai unic posibil, așa că, în practică, ar trebui să folosiți un IV aleatoriu. Acest lucru înseamnă că încorporarea acestuia în aplicație nu este o opțiune. Eu aș salva IV-ul în fișierul date pentru că nu afectează securitatea. atâta timp cât IV este aleatoriu/unic..

Comentarii

  • În cele din urmă, ideea este de a ne asigura că un hacker nu poate deschide fișierul criptat. Dimensiunea IV pare să fie mai mică decât dimensiunea cheii. Dacă cheia este fixă și IV este variabilă, așa cum ați sugerat, un hacker va avea la dispoziție un număr mai mic de combinații pentru a încerca să spargă fișierul. Este ceva ce îmi scapă? –  > Por Peter.
  • IV nu are rolul de a „asigura că un hacker nu poate sparge fișierul criptat”. Ci pentru a se asigura că, dacă criptați același fișier de două ori, acesta va produce o ieșire criptată diferită. –  > Por bdonlan.
  • bdolan Mesajul ăsta micuț a făcut ca moneda să cadă pentru mine… Mă chinuiam să înțeleg cum de este important IV-ul în comparație cu lungimea mesajului, dar văd că nu este chiar așa, ci în schimb este important în comparație cu conținutul mesajului… Mulțumesc! –  > Por DusteD.
LinconFive

IV este folosit pentru a crește securitatea prin intermediul aleatoriei, dar asta nu înseamnă că este folosit de toți algoritmii, adică…

Chestiunea capcană este cât de lung ar trebui să fie IV-ul? De obicei, este de aceeași dimensiune cu dimensiunea blocului sau cu dimensiunea cifrului. De exemplu, AES ar avea 16 octeți pentru IV. În plus, se poate selecta și tipul de IV, de exemplu eseqiv, seqiv, chainiv …