Distingerea IV corectă de IV incorectă în AES CBC atunci când cheia este cunoscută

În prezent, folosesc o valoare IV statică pentru toate criptarea și decriptarea, dar aș dori ca aceasta să fie dinamică pentru fiecare cerere de criptare/decriptare, așa că am început să folosesc un nou octet[16] și funcționează. Problema este cum să detectăm și să decriptați datele vechi. Mai jos este codul meu de decriptat și trec IV static stocat pe un secret în keyvault.

octet static privat[] DecryptFromBytes_Aes(byte[] dataBytes, byte[] cheie, byte[] iV)
    {
        if (dataBytes == null || dataBytes.Length <= 0)
            aruncă un nou ArgumentNullException ("DataBytes");
        if (cheie == null || cheie.Lungime <= 0)
            arunca ArgumentNullException nou ("cheie");
        dacă (iV == nul || iV.Lungime <= 0)
            arunca un nou ArgumentNullException("iV");

        byte[] rezultat = nul;
        folosind (AesCryptoServiceProvider aesAlg = nou AesCryptoServiceProvider())
        {
            aesAlg.Key = cheie;
            aesAlg.IV = iV;
            aesAlg.Padding = PaddingMode.PKCS7;
            ICryptoTransform decryptor = aesAlg.CreateDecryptor(aesAlg.Key, aesAlg.IV);
            folosind (MemoryStream memoryStream = new MemoryStream(dataBytes))
            {
                folosind (CryptoStream cryptoStream = new CryptoStream(memoryStream, decryptor, CryptoStreamMode.Read))
                {
                    byte[] decryptedBytes = octet nou[dataBytes.Length];
                    int read = cryptoStream.Read(decryptedBytes, 0, dataBytes.Length);
                    Array.Resize (ref decryptedBytes, citire);
                    rezultat = decryptedBytes;
                }
            }

        }

        returnează rezultatul;
    }

Problema este cum să detectați și să decriptați datele vechi. Mai jos este codul meu de decriptat și trec IV static stocat pe un secret în keyvault.

Răspunsul se bazează pe umplutura și corectitudinea cheii.

• Caz: Dacă cheia este corectă și IV nu;

  Amintiți-vă că decriptarea CBC a fost executată ca \begin{align} P_1 =& Dec_k(C_1) \oplus IV\ P_i =& Dec_k(C_i) \oplus C_{i-1},\;\; 1 < i \leq nb, \end{align}

  Prin urmare, dacă IV nu este corect, atunci primul bloc $P_1$ nu este corect. Putem considera acest lucru similar cu atac de întorsătură de biți în primul bloc. Următoarele blocuri $P_i$ vor decripta corect, deoarece se bazează pe corectitudinea $C_i$ și $C_{i-1}$ și în acest caz, sunt corecte. Doar primul blocaj va fi incorect. Distingerea acestui lucru poate fi dificilă și trebuie să pregătiți un filtru pentru a-l deosebi de proprietățile textului simplu - limba sau formatul. Este necesară compararea celor două cazuri; este IV static sau IV aleatoriu. Oricare trece filtrul dvs. poate fi cazul corect și acest lucru depinde într-adevăr de datele dvs.

  Dacă primul bloc al textului simplu este text pur și conține doar caractere din prima parte a lui ASCII (adică valoarea int a lui char < 128), atunci acesta este un bun deosebitor. Doar verificați dacă fiecare 16 octeți < 128.

  Migrați toate fișierele într-un format unic cât mai curând posibil.

• Caz: Dacă cheia nu este corecta atunci veți obține o eroare de umplere PKCS#7 cu o probabilitate mare.

  Octeții de completare vor fi unul dintre următoarele la sfârșitul textului simplu, în funcție de dimensiunea textului simplu.Cu umplutură, dimensiunea trebuie să fie un multiplu minim al mărimii blocului AES, care are o dimensiune a blocului de 16 octeți.

    lipsește 1 octet - octeți de completare: 01
    lipsesc 2 octeți - octeți de completare: 02 02
    lipsesc 3 octeți - octeți de completare: 03 03 03
    lipsesc 4 octeți - octeți de umplutură: 04 04 04 04
    lipsesc 5 octeți - octeți de completare: 05 05 05 05 05
    lipsesc 6 octeți - octeți de completare: 06 06 06 06 06 06
    ...
    bloc complet - octeți de completare: 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 
    Chiar dacă textul simplu este un multiplu de 128, este necesar un bloc complet, astfel încât umplutura să nu fie ambioasă.
  

  Verificați dacă umplutura este corectă.

  Dacă nu este corect, puteți fi sigur că IV nu este corect. Dacă este corect, există un $1/256$ probabilitatea ca IV-ul să genereze un valid aleatoriu 01 umplutura, cu $1/(256)^2$ probabilitate 0202 umplutură valabilă și așa mai departe. Pentru a elimina această posibilitate, trebuie să verificați datele. Limba sau orice alt format despre textul simplu vă poate ajuta să eliminați falsele pozitive.

Nu puteți verifica în mod fiabil dacă datele au un prefix aleatoriu sau nu. Pentru aceeași cheie, datele nu vor eșua nici măcar în general despachetarea. Deci, ceea ce trebuie să faceți este să utilizați un alt protocol.

De exemplu, puteți avea o magie complet aleatorie de 16 octeți în fața noilor fișiere criptate (generate o dată, desigur), apoi un număr de versiune și alte date, inclusiv un IV aleatoriu, text cifrat și un HMAC peste antet și date inclusiv a IV-a. În acest fel, puteți detecta că este utilizată criptarea corectă (deoarece generarea acelei magii accidental are o probabilitate de 1 în $2^{128}$) prin simpla comparare. De asemenea, v-ați protejat fișierul pentru integritate și autenticitate folosind HMAC (acest lucru este opțional și nu este strict necesar pentru confidențialitate - dar este foarte recomandat).

Deci asta ar fi:

 MAGIC (16 octeți) | VERSIUNEA | IV (16 octeți) | CIPHERTEXT | ETICHETĂ

Unde TAG este eticheta de autentificare produsă folosind HMAC peste tot ce a fost înainte.

Desigur, au existat mulți oameni care au scris deja protocoale ca acestea, așa că este posibil să doriți să căutați formate de containere, cum ar fi CMS (care depinde de obicei de criptarea / certificatele cu cheia publică) sau chiar NaCL.