GCM (Galois / Counter Mode), în special în combinație cu AES, a fost un standard de aur de facto de ani de zile. Criptați și autentificați într-un singur pas, ceea ce este prea minunat, iar termeni precum AEAD funcționează bine pentru a impresiona o fată, așa că ar fi câștigător. Dar, glumiți deoparte …
Am ” M-am întrebat întotdeauna ce o face atât de specială și, cu cât mă gândesc mai mult la asta, cu atât înțeleg mai puțin. Dacă te uiți la ea, atunci magia generală nu este deloc atât de minunată. Sau poate că sunt prea prost ca să o potrivi (de aici și întrebarea mea).
Gândurile mele:
În primul rând, GCM este o formă de mod contor . Ceea ce înseamnă că spre deosebire de de ex. înlănțuirea blocurilor cifrate, ieșirea unui bloc depinde exact de un bloc de intrare. Mai rău, totuși: puteți modifica un singur bit, iar rezultatul decriptat va diferi exact în acel bit. Deoarece, dacă sunteți sincer, un cifru de bloc în modul contor nu este deloc un ” cifru de bloc „, ci un PRNG (cu cheie) urmată de o operație XOR. Practic un cifru de flux ” blocky „. Nu este nevoie de mult pentru a-ți imagina un scenariu în care cineva ar putea abuza de acest lucru pentru a schimba mesajele într-un mod dăunător (de exemplu, schimba tranzacția „: +5.000 \ $ ” la ” tranzacție: -5.000 \ $ „). Cifrele de blocuri au, în mod normal, proprietatea înnăscută de a se transforma în tâmpenii complete pe măsură ce întoarceți un singur bit (plus, cu înlănțuirea, tot restul mesajului). Aceasta este de fapt o proprietate destul de drăguță și de dorit, pe care tocmai am aruncat-o peste bord fără niciun motiv întemeiat.
Sigur, cu autentificatorul , atacul de mai sus este dificil de realizat, deoarece manipularea va fi descoperită. Dar, în principiu, autentificatorul remediază doar problema alegerii modului de funcționare introdus .
GHASH este un MAC care acceptă date autentificate suplimentar. Din ceea ce pot să spun, este o minciună directă. Sau numiți-o ” exagerare optimistă ” dacă vreți. Este doar o funcție de compresie cu matematică non-intuitivă (pentru non-matematicieni) în spate, dar în cele din urmă nu face altceva decât o simplă multiplicare și aruncarea a jumătate din biții de intrare cu echivalentul ” depășire „. Ceea ce se poate face, cu o matematică mai banală, în două linii de cod C pe bloc în decurs de o duzină de cicluri (sau dacă sunteți bine să folosiți multiplicări pe 32 de biți, mai degrabă decât 64, se poate face în paralel, de exemplu cu AVX2 ” s vpmulld pentru două blocuri complete în ~ 4 cicluri).
Cei care încă își amintesc IDEA își vor aminti că au folosit add mod 2 16 și multiplication mod 2 16 + 1 ca S-box-uri care au avut proprietatea frumoasă de a fi reversibilă (cam necesară dacă doriți să decriptați). Din fericire, acest lucru nu poate fi extins la 32 de biți, deoarece 2 32 +1 nu este număr prim, deci nu toate intrările sunt garantate pentru a fi relativ prime pentru acesta și, prin urmare, aveți probleme la inversarea operației. Dar … asta este foarte bine în cazul nostru, nu vrem funcția noastră de compresie să fie inversabilă! Deci, într-adevăr, ” simplu „, înmulțirea obișnuită ar trebui să facă și el trucul?
Deci, acea compresie simplă, nespecială, fără magie funcția se întâmplă să fie inițiată cu cheia și IV, ceea ce, în mod incidental, face ca ieșirea finală să depindă de cheie într-un fel sau altul, deci acea funcție obișnuită devine efectiv un MAC. Dacă aveți ” date suplimentare „, trebuie doar să le introduceți în hash înainte de a vă cripta datele, gata. Din nou, acest lucru nu este ceva foarte special.
În general, nu este nimic pe care să nu-l poți realiza cu aproape orice altă funcție hash , de asemenea.
Acum, Galois / counter presupune că se va utiliza modul counter. Modul Counter (și derivatele sale), precum și GHASH au avantajul că puteți cripta / decripta blocuri în paralel. De asemenea, GHASH este paralel în mod banal.
Da, performanță ! Dar să fim sinceri, acesta este într-adevăr un avantaj, sau mai degrabă un imens dezavantaj ?
Contează cât timp durează descifrarea unei dimensiuni de gigabyte sau terabyte mesaj și cât de bine puteți paralela acea lucrare? Sau aplicații în care doriți absolut să puteți ” căuta ” în poziții aleatorii? Ei bine, există aplicații în care acest lucru poate conta, sigur. Îmi vine în minte criptarea completă a discului. Dar nu ați dori să utilizați GCM în acest caz, deoarece doriți ca dimensiunea de intrare și dimensiunea de ieșire să fie identice.
Pentru un server ocupat (sau VPN), va conta, , dar acestea pot procesa orice în paralel oricum, deoarece au multe conexiuni simultane.Deci, dacă puteți paralela sau nu fluxul one nu face nicio diferență în ansamblu. Dar aplicațiile în care există doar puține conexiuni? Ei bine, în mod normal, nu transmiteți terabyți de date pe un terminal de conectare și, dacă da, conexiunea dvs. la internet este probabil probabil factorul limitativ oricum, deoarece performanța single-core depășește cu ușurință lățimea de bandă GbE chiar și pe procesoarele desktop de 7-8 ani .
Bine, s-ar putea să trebuiască să așteptați 2-3 secunde mai mult atunci când extrageți un fișier criptat de 2 TB 7z pe hard disk (dacă crearea a mii de intrări de director nu este într-adevăr blocajul, pe care eu sunt înclinat să cred că va fi cazul). Cât de des ați făcut asta în ultimul an? Eu: zero ori.
Singurii pentru care face cu adevărat diferența sunt ” băieți răi „, adică exact cei pe care nu doriți să aveți o viață ușoară. Destul de sigur, dacă puteți paralela în mod trivial, atacurile devin mult mai ușoare. Aruncați o cameră plină de hardware dedicat (GPU-uri, FPGA-uri, orice) la problemă și lăsați-o să se distrugă. Nu este necesară comunicarea între noduri? Ei bine, perfect, nu se poate îmbunătăți.
Este într-adevăr un avantaj? Nu știu, pentru mine mi se pare un dezavantaj imens. Dacă ar fi ceva, aș vrea să fac paralelizarea cât mai tare posibil, nu cât mai ușor posibil.
Deci … suficient de meditat, și la întrebarea:
Care este lucru fundamental care îmi lipsește despre GCM, ceea ce îl face atât de minunat încât ar trebui să-l folosești absolut?
Comentarii
- Dar doar cine sunt ” băieții răi ” este imposibil de definit. Și acest lucru are un impact UMIL asupra recomandărilor guvernamentale și a răspunsurilor din acest forum.
Răspuns
TL; DR: GCM oferă performanțe excelente cu cele mai bune proprietăți de securitate pe care le așteptăm astăzi de la cifre (AEAD).
GCM folosește CTR pentru a construi un flux de cifrare. Aceasta este o metodă bine studiată, care are un singur dezavantaj: are absolut nevoie de o autentificare pentru a preveni flipping-ul de biți. Înainte de GCM, CTR-apoi-MAC era soluția. Un avantaj principal al cifrelor de flux este absența atacurilor de umplere (deoarece nu este nevoie de umplere). Un alt avantaj este că AES-CTR poate beneficia de instrucțiunile AES-NI.
GCM este CTR-apoi-MAC cu performanță mai bună . O îmbunătățire cheie față de CRT-apoi-MAC este capacitatea de a suprapune execuția criptării și autentificării. Mai mult, s-a dovedit că este sigur în modelul concret de securitate și nu este împiedicat de brevete, așa că „nu este de gând să îl folosești.
Are unele dezavantaje: nu este eficient în hardware-ul încorporat și este greu de implementat eficient. Ultimul punct este contracarat prin utilizarea bibliotecilor scrise de alții. Cu toate acestea, acestea sunt motivele pentru care xchacha20-poly1305 a devenit popular în GCM.
Comentarii
- Aș argumenta un alt motiv pentru care ChaCha20 a câștigat popularitate pentru că este nu AES. Nu
nu mă înțelegeți greșit, AES este un algoritm minunat, dar a pune literalmente toate ouăle noastre într-un coș poate nu este cel mai inteligent dintre toate ideile. Și a avea un alt algoritm bine testat în afară de AES este destul de valoros
Răspuns
În primul rând, GCM este o formă de contor. Ceea ce înseamnă că spre deosebire de de ex. înlănțuirea blocurilor cifrate, ieșirea unui bloc depinde exact de un bloc de intrare. Mai rău, totuși: puteți modifica un singur bit, iar rezultatul decriptat va diferi exact în acel bit. Pentru că, dacă sunteți sincer, un cifru bloc în modul contor nu este deloc un „cifru bloc”, ci un PRNG (cu cheie) urmat de o operație XOR. Practic un cifru de flux „blocat”. Nu este nevoie de mult pentru a-ți imagina un scenariu în care cineva ar putea abuza de acest lucru pentru a schimba mesajele într-un mod dăunător (de exemplu, schimba tranzacția „: +5.000 \ $” la „tranzacție: -5.000 \ $”).
Autentificarea mesajelor pe care straturile GCM de pe partea superioară a CTR-ului îi fac maleabilitatea lipsită de importanță.
Cifrele de blocuri au, în mod normal, proprietatea înnăscută de a se transforma în tâmpenii în timp ce răsuciți un singur bit (plus, cu înlănțuirea, întregul rest al mesajului) . Aceasta este, de fapt, o proprietate destul de drăguță și de dorit, pe care tocmai am aruncat-o peste bord, fără un motiv întemeiat.
Acest lucru este foarte, foarte greșit. În primul rând , Modul CBC suferă, de asemenea, de un fel de slăbiciune de maleabilitate; dacă răsuciți un bit din textul cifrat, amestecați doar un bloc și răsuciți bitul corespunzător al blocului net. Și există alte atacuri de maleabilitate împotriva CBC; consultați, de exemplu, atacul EFail .
Mai general, ideea ta informală despre mesaje „transformându-se în tâmpenii complete” nu este suficient de bună. Avem absolut nevoie de computere pentru a detecta mecanic, cu un răspuns clar „da / nu”, atunci când a fost falsificat un mesaj criptat. Având încredere că un om va fi în buclă suficient de devreme pentru a observa „tâmpenii” nu este „suficient.
GHASH este un MAC care acceptă date extra autentificate. Din ceea ce pot să spun, aceasta este o minciună directă. Sau numiți-o „exagerare optimistă”, dacă vreți. Este doar o funcție de compresie cu matematică non-intuitivă (pentru non-matematicieni) în spate, dar în cele din urmă nu face altceva decât o simplă multiplicare și aruncarea a jumătate din biții de intrare cu echivalentul „overflow”.
MAC-ul nu funcționează, deoarece utilizatorii nu înțeleg matematica. E ca și cum ai spune că oamenii nu se pot uita la televiziune prin satelit, deoarece nu Nu știu calculul. MAC-urile cu câmp finit sunt o construcție standard, cunoscută de decenii în urmă.
Ceea ce se poate face, cu o matematică mai banală, în două linii de C cod pe bloc în decurs de o duzină de cicluri (sau dacă sunteți în regulă cu utilizarea multiplicărilor pe 32 de biți, mai degrabă decât 64, se poate face în paralel, de exemplu, cu AVX2 „s vpmulld pentru două blocuri complete în ~ 4 cicluri).
Există o dezbatere reală cu privire la faptul dacă MAC-urile bazate pe câmpuri Galois precum GHASH sau MAC-urile bazate pe câmpuri prime cum ar fi Poly1305 sunt o alegere mai practică. Multe dintre acestea se bazează pe compromisuri între proiectarea MAC-urilor pentru a sublinia implementările software vs. hardware; de exemplu, multiplicările câmpului Galois sunt de coșmar în software, dar mult mai simple decât înmulțirile aritmetice din hardware. O bună parte din compromisuri se bazează, de asemenea, pe vulnerabilitatea la atacurile pe canale laterale, de exemplu, analiza puterii .
Dar nu există o dezbatere dacă fie câmpurile Galois, fie câmpurile prime sunt fundamental nesou nd. Matematica verifică ambele.
Da, performanță! Dar să fim sinceri, acesta este într-adevăr un avantaj, sau mai degrabă un dezavantaj imens?
Spuneți-le paradelor nesfârșite ale inginerilor de-a lungul deceniilor au rezistat adăugării criptării produselor din cauza performanței. Și nu vă gândiți doar la computere puternice; gândiți-vă la dispozitivele încorporate și fiți foarte speriați de Internetul obiectelor.
Adică, nu este deloc o problemă moartă. În ultimii câțiva ani a avut loc o dezbatere puternică și dezvoltarea unei noi construcții criptografice pentru a sprijini criptarea pe disc complet pe dispozitivele Android de ultimă generație care au fost judecate nu este suficient de puternic pentru algoritmii bazati pe AES pe care Android i-a oferit anterior.
Singurii pentru care [performanța] face cu adevărat diferența sunt „băieții răi”, adică exact cei pe care nu doriți să-i aveți viață ușoară. Destul de sigur, dacă puteți paralela în mod banal, atacurile devin mult mai ușoare. Aruncați o cameră plină de hardware dedicat (GPU-uri, FPGA, orice) la problemă și lăsați-o să se distrugă.
Cifrele rezolvă acest lucru folosind dimensiuni de cheie suficient de mari, nu făcând ca cifrele să încetinească. Preocuparea pe care o aduceți apare în criptografia bazată pe parolă unde nu „Nu aveți chei secrete suficient de entropice. Cheile simetrice de 256 de biți vor fi pentru totdeauna mai mult decât suficient de mari pentru a învinge orice atac de forță brută din universul nostru.
Ce este elementul fundamental care îmi lipsește despre GCM, care îl face atât de minunat încât ar trebui să-l folosești absolut?
Nu trebuie să folosești GCM . Este în același timp:
- Fundamentall Sunet și foarte susținut în hardware;
- Grevat de o serie de dezavantaje pe care nu le-ați adus, cum ar fi performanța slabă a software-ului și eșecul catastrofal al autenticității la refolosirea nonce, care deseori îl descalifică în anumite contexte practice. .
Dacă aveți hardware care are suport nativ AES-GCM și un software bine auditat care îl utilizează, nu ar fi înțelept să nu îl aveți printre cei mai buni candidați.