Ceea ce se pare că cereți este un tip de cheie publică criptare convergentă, pentru care există diverse scheme.
Cu toate acestea, toate astfel de scheme sunt inevitabil vulnerabile la atacurile de ghicire cu forță brută dacă numărul de texte clare plauzibile este scăzut – să zicem, mai puțin de aproximativ un septillion (10$^{24} â 2^{80}$).
Mai exact, un atacator care are un text cifrat convergent (sau doar un hash criptografic) al unui mesaj și cheia publică (dacă există) folosită pentru a-l genera poate ghici un text simplu plauzibil, îl criptează și îl compara cu textul cifrat/hash pentru a verifica dacă sau nu presupunerea lor a fost corectă.
Un CPU obișnuit de desktop poate face aproximativ un miliard (10$^9 â 2^{30}$) criptări o secundă, deci dacă există mai puține texte clare probabile decât atât, schema nu oferă deloc securitate reală. Și dacă atacatorul este dispus să petreacă puțin mai mult timp și/sau să cumpere (sau să fure) puțin mai multă putere de calcul decât atât, probabil că își poate trece cu forța brută de o mie, un milion sau un miliard de ori mai multe texte clare. De asemenea, atacarea simultană a mai multor texte cifrate în acest mod este la fel de rapidă ca și atacul unui singur text.
A întinderea cheii schema poate fi folosită pentru a încetini astfel de atacuri, dar numai cu prețul încetinirii operațiunilor legitime de criptare (și decriptare) cu aproximativ același factor. Deci, de exemplu, dacă puteți trăi cu o singură operațiune de criptare care durează aproximativ o secundă CPU, puteți forța atacatorul să ia și aproximativ o secundă CPU (dați sau luați un factor de 10 sau 100, în funcție de eficiența implementării) pentru a ghici și testați un singur text clar plauzibil. Dar asta înseamnă totuși că un atacator cu acces la 100 de procesoare (sau, eventual, ~un GPU rapid) poate testa încă un milion de texte clare posibile în aproximativ trei ore.
De obicei, datele precum adresele de e-mail, numele de utilizator, numerele de telefon etc. au o cardinalitate destul de scăzută – și mai rău, chiar dacă ar putea exista milioane sau miliarde de posibil adrese, the probabil combinațiile de adrese utilizate sunt mult mai puține și ușor de descoperit folosind hărți publice și baze de date de adrese. Deci, în practică, folosirea hashingului criptografic sau a criptării convergente pentru a pseudonimiza astfel de date este sortită eșecului.
Ceea ce puteți face, în schimb, este unul dintre următoarele (în ordinea aproximativ descrescătoare a preferințelor):
Nu stocați și nu procesați astfel de date dacă le puteți evita.
Dacă trebuie să stocați astfel de date, stocați-le criptate (folosind o metodă convențională atac cu text clar ales schemă de criptare rezistentă) și doar decriptați-o pentru procesare pe un sistem securizat. Păstrați cheia de decriptare în siguranță.
Dacă trebuie să pseudonimizați astfel de date, de ex. pentru procesarea de către terți neîncrezători, faceți-o de preferință asociind fiecare dată (adresă, nume de utilizator etc.) cu un identificator complet aleatoriu și stocând asocierile într-o bază de date criptată. Asigurați-vă că păstrați în siguranță această bază de date de asociere așa cum este descris mai sus.
Alternativ, puteți genera identificatorii pseudonimi prin aplicarea a PRF (precum HMAC sau ceva întindere a tastelor KDF) la elementele de date sensibile cu o cheie secretă. Dacă da, tu trebuie sa protejați cheia PRF de compromisuri, deoarece poate fi folosită pentru a depseudonimiza toate datele.
Oricum ar fi, în general, nu este fezabil să se facă pseudonimizare „la sursă”. În schimb, ar trebui să criptați orice date sensibile folosind o schemă securizată de chei publice la punctul de colectare (care ar trebui să numai au acces la jumătatea publică a perechii de chei), colectează aceste date criptate într-un sistem securizat și le decriptează, procesează și (opțional) le pseudonimizează acolo.
