Am nevoie de o sare când obțin chei noi cu HKDF dacă cheia principală este puternică? Este ok o sare globala?

Să presupunem că am o cheie principală și vreau să o folosesc pentru a obține chei noi pe care să le folosesc pentru criptare, folosind HKDF. Totuși, sunt puțin confuz în ceea ce privește utilizarea sării. Am mai văzut și alte postări despre el aici, dar încă nu înțeleg pe deplin când/dacă ar trebui să-l folosesc.

Scenariu: A creează o cheie principală și o partajează cu B, C, D. A derivă chei diferite pentru B, C și D și criptează unele date (pentru fiecare dintre ele). Acum vreau ca ei să poată obține aceleași chei noi pe baza unor intrări, astfel încât să își poată decripta datele.

HKDF(MasterKey, sare: "", informații: "unele-date-B", hash: "SHA256")
HKDF(MasterKey, sare: "", informații: "unele-date-C", hash: "SHA256")
HKDF(MasterKey, sare: "", informații: "unele-date-D", hash: "SHA256")
...

Sarea de aici este opțională, dar folosirea ei adaugă „tărie”. Este util doar dacă MasterKey este slabă?

Dacă MasterKey-ul meu este „suficient” de puternic – mai am nevoie de sare? Dacă nu, ce este suficient de puternic? Este suficient un șir hexagonal aleator de 32 de caractere?

Dacă tot ar trebui să folosesc o sare, este în regulă ca toate B, C și D să împartă aceeași sare sau trebuie să fie unice (în RFC se menționează că sarea poate fi refolosită, dar nu sunt complet sigur ce înseamnă)?

Sarea de aici este opțională, dar folosirea ei adaugă „tărie”. Este util doar dacă MasterKey este slabă?

Dacă cheia principală nu este uniform aleatorie, atunci etapa de extragere extrage aleatoriu uniform din entropia curentă a materialului cheie de intrare (IKM) (parola sau cheia dvs. sau ..). Sarea se adaugă la întărirea HKDF și ajută la extracția independentă de sursă, astfel încât două IKM diferite se termină cu două rezultate extrase diferite. Se poate beneficia de extracția independentă de sursă, chiar dacă au cheie aleatoare uniformă cu suficientă putere

Dacă MasterKey-ul meu este „suficient” de puternic – mai am nevoie de sare? Dacă nu, ce este suficient de puternic? Este suficient un șir hexagonal aleator de 32 de caractere?

Puternic nu este metrica. Dacă aveți biți aleatori uniformi, atunci nu aveți nevoie de etapa de extragere a HKDF. Dimensiunea biților depinde de locul în care veți folosi; 128 de biți pentru AES-128, 256 de biți AES-256 etc.

Dacă tot ar trebui să folosesc o sare, este în regulă ca toți B, C și D să împartă aceeași sare sau trebuie să fie unice (în RFC se menționează că sarea poate fi refolosită, dar nu sunt complet sigur ce înseamnă)?

De fapt, odată ce obțineți o Cheie PseudoRandom (PRK) din pasul Extragere, pentru a obține cheile trebuie doar să schimbați eticheta de informații.

Reutilizarea sării înseamnă că nu există extracție independentă de sursă, extindeți același PRK pe extinde pasul. Este posibil să doriți să utilizați diferite PRK pentru diferiți utilizatori.

Este ok o sare globala?

Pasul de extindere folosește HMAC cu cheia PRK.

HMAC-Hash(PRK, T(0) | informații | 0x01)

HMAC este un PRF și folosești sare globală, apoi repari PRF-ul. Singura problemă pe care o pot vedea este ciocnirea ieșirii pe termen lung. În timp ce se poate genera și stoca săruri cu ușurință și se poate obține o familie de PRF-uri în loc de una, așa că de ce să nu folosiți săruri diferite pentru fiecare utilizator?

Există două secțiuni grozave în rfc5869

3.1. Sare sau fără sare

Cu toate acestea, chiar și o valoare a sării de mai puțină calitate (mai scurtă în dimensiune sau cu entropie limitată) poate face totuși o semnificativă contribuția la securitatea materialului de codare de ieșire; designeri de aplicații sunt prin urmare încurajate să furnizeze valori de sare pentru HKDF dacă astfel de valori pot fi obținute de către aplicație.

unele aplicații pot avea chiar și o valoare secretă de sare disponibilă pentru utilizare; într-un astfel de caz, HKDF oferă o garanție de securitate și mai puternică.

3.2 Intrarea „informații” în HKDF ...Obiectivul său principal este de a lega materialul cheie derivat de informații specifice aplicației și contextului. De exemplu, „informații” poate conține un număr de protocol, identificatori de algoritm, identități de utilizator etc. În special, poate împiedica derivarea aceluiași material de introducere a cheii pentru contexte diferite (când același material de cheie de intrare (IKM) este utilizat într-un astfel de contexte diferite).

De fapt, aceasta nu este modalitatea corectă de a genera și distribui cheia. Ar trebui să luați în considerare soluțiile de criptare cu cheie publică, cum ar fi RSA-KEM sau ECHE, unde rezultatul ambelor trebuie să fie transmis de la un KDF înainte de a fi utilizat pentru criptare.