Criptare cheie: trebuie să fie autentificată?

Alice vrea să stocheze fișiere $m_i$ pe platforma de stocare cloud neîncrezătoare a lui Bob, cu restricția suplimentară că poate stoca o singură cheie principală $k$ se.

Ea criptează fișierele cu chei $k_i$ respectiv şi obţine $c_i := Enc_{k_i}(m_i) $. Ea criptează, de asemenea, cheile ca $k'_i := Enc_k(k_i)$ și trimite tuplurile $(k'_i,c_i)$ lui Bob să depoziteze.

Pare destul de natural că modul de criptare folosit pentru $c_i$ fi criptare autentificată. Dar pentru $k'_i$, din cauza naturii de entropie ridicată a încărcăturii utile și a faptului că acestea sunt folosite doar pentru decriptarea criptării autentificate, se pare că criptarea $Enc_k(k_i)$ nu trebuie autentificat.

E adevarat? Dacă da, care este un argument mai formal și mai coerent pentru aceasta? Dacă nu, ce atac permite această relaxare?

Dacă a fost posibil ca un cifr AEAD să valideze când cheia greșită a fost folosită o cheie aleatorie, atunci cred că cifrul ar fi considerat nesigur. Ca atare, cred că excluderea cheii în calcul ar face o mare diferență.

Pe de altă parte, este puțin probabil până la extrem ca un AD de intrare să fie tratat ca cheie într-un cifru bloc. Prin urmare, includerea acestuia în AD nu ar trebui să facă nesiguri majoritatea algoritmilor. Totuși, sunt puțin îngrijorat de algoritmul MAC intern; s-ar putea să existe o relație matematică ciudată care ar putea fi exploatată; Nu cred că există o cerință specifică pentru a evita asta.

În general, totuși, nu aș trata o cheie ca pe date. Probabil că este mai periculos și mai complicat din punct de vedere al designului. Cheile pot fi stocate în containere care nu fac datele disponibile (de exemplu, într-un depozit de chei hardware sau TPM). Chiar dacă nu intenționați să utilizați chei protejate în acest moment, aceasta ar exclude această opțiune în viitor.

Deci, ce alte opțiuni există:

1. Includeți textul cifrat al cheii împachetate ca date AEAD. Astfel cheia este dublu protejată. Cu toate acestea, dacă utilizați modul greșit (cum ar fi modul contor), atunci un atacator ar putea face modificări pe bit în cheie și date suplimentare, ceea ce m-ar face un pic inconfortabil. Așa că aș folosi un mod de împachetare cheie conceput pentru acest scop în acest caz, sau reveniți la CBC cu un IV zero (yuk). Acest lucru nu ar trebui să ofere atacatorului un control foarte mare asupra valorii cheii.

2. În loc să împachetați cheile, derivați cheile folosind datele de derivare a cheilor (de exemplu, etichetă / informații / contor de secvență / sare) stocate cu textul cifrat. Dacă doriți, puteți include datele de derivare a cheii stocate în AD.Acest lucru are dezavantajul că nu puteți utiliza direct chei aleatorii (generate local) pentru a cripta datele.

Concluzie: aș fi mai îngrijorat de modul în care împachetați sau obțineți cheile utilizate cu datele. Includerea cheilor derivate în sine în AD este o idee proastă, dar tu ar putea include alte date precum textul cifrat sau datele de derivare din AD și îngreunează un adversar să creeze o combinație cheie/text cifrat.

Pe lângă modul special de împachetare, aș recomanda și folosirea tastelor pe 256 de biți pentru a evita atacurile multi-țintă. Utilizarea unui mod special de împachetare sau derivarea cheii ar proteja împotriva atacurilor asociate cheilor. Cu acest tip de caz de utilizare este posibil să vă faceți griji modificări în fișiere și adversarii schimbă conținutul text cifrat al fișierelor.