Octeții pe care îi XOR cu mesajul pentru a obține textul cifrat se numesc fluxul cheie. Este sigur să creați un flux de chei folosind un CSPRNG da, un generator de numere pseudo-aleatoare securizat criptografic și un seed static.
Cu toate acestea, există probleme practice dacă utilizați CSPRNG al sistemului dvs.:
- poate decide să (re)sămânțea ocazional;
- algoritmul se poate schimba în timp sau între sisteme;
- modul în care sunt extrași octeții aleatori se poate schimba (de exemplu, poate decide să se alinieze cuvintelor).
Deci, trebuie să vă asigurați că operațiunea CSPRNG este turnată în piatră înainte de a o folosi pentru a cripta ceva. În cel mai rău caz, sunt incluse date aleatorii pentru a-ți genera cifrul, caz în care datele se pierd efectiv. Acest s-a mai întâmplat înainte când „SHA1PRNG” al lui Sun a fost înlocuit mai întâi cu un alt algoritm și apoi cu date aleatorii OpenSSL pe Android.
Teoretic vorbind, un cifr de flux - sau un cifr de bloc într-un mod de flux - sunt ambele CSPRNG în care există o sămânță (combinația de cheie și IV/nonce), un algoritm specific și o modalitate prescrisă de a prelua un flux cheie. Deci, în general, răspunsul plictisitor este să utilizați AES-CTR pentru a crea fluxul de cheie și să utilizați AES-GCM - care utilizează AES-CTR intern - dacă aveți nevoie și de autentificarea mesajelor. Pe sistemele fără accelerare hardware, ar putea fi utilizat un cifr de flux precum ChaCha20.
Puțin mai puțin plictisitor, puteți, de asemenea, să construiți un cifr de flux dintr-o funcție hash utilizând modul contor. De preferință, ați folosi o construcție MAC precum HMAC pentru asta. De fapt, majoritatea CSPRNG-urilor pe care le furnizează sistemele nu sunt cu mult mai mult decât atât - dar, așa cum am menționat, sunt de obicei concepute pentru a furniza date aleatorii, nu date deterministe. Și da, în general, acești algoritmi sunt mai lenți decât un cifr de flux dedicat sau un cifr bloc accelerat hardware - sunt mai complex mai degrabă decât mai puțin complexă.
