AES256-GCM – poate cineva să explice cum să-l folosească în siguranță (rubin)
On decembrie 31, 2020 by adminCaut să folosesc AES256-GCM pentru criptarea câmpurilor bazei de date. Știu că pentru AES256-CBC, trebuie să generez un nou IV pentru fiecare criptare, dar pot folosi aceeași cheie. IV-ul poate fi stocat deschis alături de textul cifrat (adică poate fi public).
Am început să citesc despre GCM, dar nu prea înțeleg unele lucruri. Pe acest thread Stackexchange , se afirmă că:
- GCM nu are nevoie de un IV furnizat.
- Eticheta asociată nu este necesară, dar poate îmbunătăți securitatea (exemplul pe care l-au dat este utilizarea unui id de bază de date)
Dar Wikipedia afirmă despre GCM :
GCM a fost s-a dovedit sigur în modelul de securitate concret. [ 13 ] Este sigur când este utilizat cu un mod de operare cu cifrare bloc care este nu se distinge de o permutare aleatorie; totuși securitatea depinde de alegerea unui vector de inițializare unic pentru fiecare criptare efectuată cu aceeași cheie (consultați atac de cifrare a fluxului ).
-
Ceea ce înseamnă că IV trebuie încă generat aleatoriu și furnizat pentru fiecare criptare cu GCM, așa că de ce utilizatorul în mesajul de răspuns stackexchange spune că nu suntem obligați să furnizăm IV?
Wikipedia precizează, de asemenea:
Puterea autentificării depinde de lungimea etichetei de autentificare, ca și în cazul tuturor codurilor de autentificare a mesajelor simetrice. Cu toate acestea, este descurajată utilizarea etichetelor de autentificare mai scurte cu GCM. Lungimea de biți a etichetei, notată t, este un parametru de securitate. În general, poate fi una dintre următoarele cinci valori: 128, 120, 112, 104 sau 96.
-
În postarea OP din acel thread stackchange, OP folosește
tag = cipher.auth_tag
. Este implicit 96? Dacă da, există o modalitate de a-l schimba? Există probleme semnificative de performanță în utilizarea 128 decât 96? -
Are atât eticheta asociată (
cipher.auth_data
), cât și eticheta de autentificare (cipher.auth_tag
) trebuie ținute secrete? Sau pot fi menținute deschise ca IV? -
În sfârșit, poate cineva să explice mai departe ce se înțelege prin eticheta asociată? un exemplu din răspunsul dat în firul OP a fost că putem folosi un id de bază de date pentru a ne asigura că datele aparțin unui anumit utilizator al bazei de date. Să spunem că un utilizator are următoarele câmpuri de baze de date:
User - primary_id - encrypted_email
Și dorim să criptăm e-mailul utilizatorului înainte de inserare. Cu Utilizatorul
primary_id==10
(modificarea codului rubin al OP):cipher = OpenSSL::Cipher::AES.new(128, :GCM) cipher.encrypt key = cipher.random_key iv = cipher.random_iv cipher.auth_data = "10" # Using DB user"s id! encrypted = cipher.update(data) + cipher.final tag = cipher.auth_tag
Am înlocuit
cipher.auth_data
cu ID_primar al utilizatorului bazei de date. Este corect?
Comentarii
Răspuns
Înainte de a răspunde la întrebări: GCM este o criptare autentificată modul de operare, este compus din două funcții separate: una pentru criptare (AES-CTR) și una pentru autentificare (GMAC). Primește ca intrare:
- o cheie
- o IV unică
- Datele care trebuie procesate numai cu autentificare (date asociate)
- Datele care urmează să fie procesate prin criptare și autentificare
Se afișează:
- Datele criptate de intrare 4
- Un TAG de autentificare
TAG-ul de autentificare este o intrare în decriptare, dacă cineva a modificat datele asociate sau datele criptate, decriptarea GCM va observa acest lucru și nu va afișa nicio dată (sau nu va returna o eroare) și ar trebui să aruncați datele primite fără a le prelucra)
Acum:
Ceea ce implică faptul că IV trebuie încă generat aleatoriu și furnizat pentru fiecare criptare cu GCM, deci de ce utilizatorul din postul de răspuns StackExchange spune că nu suntem obligați să furnizăm IV?
GCM necesită un IV, este utilizat atât de AES-CTR, cât și de AES-GMAC, deci indiferent de ceea ce faceți cu GCM, aveți nevoie pentru a trece un IV. Este necesar să fie unic nu neapărat aleatoriu. De obicei, implementările au un IV pe 96 de biți și acesta este modul recomandat de a utiliza GCM conform NIST .
În postarea OP din acel fir StackExchange, OP folosește tag = cipher.auth_tag. Este implicit 96? Dacă da, există o modalitate să îl modificați? Există probleme semnificative de performanță la utilizarea 128 decât 96?
În mod implicit, eticheta de autentificare este de 128 biți. Ar trebui să furnizați eticheta de autentificare pentru receptorul mesajului dvs., deci în unele aplicații este logic să utilizați o etichetă mai mică. Rețineți că cu cât aveți o etichetă mai mică, cu atât puteți avea mai multe coliziuni. Dacă lățimea de bandă nu este o problemă, utilizați 128.
Consultați și secțiunea detaliată despre auth_tag ([tag_len] → șir aici
Este necesar ca atât eticheta asociată (cipher.auth_data), cât și eticheta de autentificare (cipher.auth_tag) să fie păstrate în secret? Sau pot fi menținute deschise ca IV?
Datele asociate (incorect ați scris Associated Tag) sunt utilizate pentru ca datele să fie cunoscute public. Exemplu sunt anteturi sau adresă de destinație. Deci, nu este necesar să fie secret, dar dacă este necesar să criptați totul, setați datele asociate la „”. Eticheta de autentificare nu trebuie să fie secretă și, de fapt, trebuie să fie furnizată receptorului necriptat (cum ar fi IV).
În sfârșit, poate cineva să explice mai departe ce se înțelege prin eticheta asociată? Exemplul din răspunsul dat în firul OP a fost că putem folosi un id de bază de date pentru a ne asigura că datele aparțin unui anumit utilizator al bazei de date. Să spunem că un utilizator are următoarele câmpuri de baze de date:
Se pare că confundați datele de autentificare și eticheta de autentificare. Datele de autentificare (sau asociate date) este ceva pe care doriți să îl protejați cu autentificare (dacă cineva îl modifică, veți ști), dar nu trebuie criptat. După cum sa menționat mai sus, acesta este de obicei cazul antetelor care trebuie citite de routerele intermediare care nu pot „decripta mesajul criptat.
Eticheta de autentificare va depinde de datele pe care le criptați și de datele asociate. Deci în decriptare, va trebui să procesați și datele asociate sau veți eșua.
În exemplul dvs., care nu este foarte clar pentru mine, autentificați ID-ul principal și adresa de e-mail și criptați e-mailul. Dacă stocați în DB atât IV-ul, cât și TAG-ul, puteți decripta e-mailul dacă este necesar. Fără o etichetă de autentificare, un atacator ar putea copia e-mail-ul utilizatorului1 în e-mail-ul utilizatorului2, dacă el copiază și IV-urile, atunci când veți căutând adresa de e-mail a utilizatorului2, veți decripta cu succes e-mailul utilizatorului 1 fără să observați nimic.
În schimb, dacă utilizați și un TAG și prelucrați ca date asociate ID-ul utilizatorului corespunzător, atunci un atacator nu ar putea faceți atacul anterior, deoarece în decriptare vom observa că datele asociate au fost nu este cea utilizată în criptare și operațiunea va eșua (veți cunoaște pe cineva manipulat cu datele utilizatorului 2).
auth_data
.auth_data
este o informație contextuală arbitrară (de exemplu, cheia principală a bazei de date a mesajului criptat sau un nume de utilizator sau un șir care acoperă acțiunea către un anumit ” scop „) care trebuie furnizat textual după decriptare. Poate fi public, dar nu ar trebui ‘ să fie controlabil de către entitatea care furnizează texte criptate pentru a fi decriptate.auth_tag
este ieșirea jumătății de autentificare a cifrului și este ceea ce se folosește la decriptare pentru a detecta orice modificări ale datelor cheie, text cifrat, IV sau autentificare. Poate fi stocat alături de ieșirea criptată.