OPENSSL: Care este diferența dintre comanda enc și comanda enc a cms?

Am găsit ceva ciudat în timp ce verificam datele din interiorul plicului.

Am avut text simplu "plaintextplant" - lungimea este $15$ (include lf(0x0A))`. Am creat un fișier .ber care este criptat de AES256 și codificat DER prin:

openssl cms -encrypt -in plain -aes256 -recip certificate.pem -outform DER -out enveloped-data.ber

Apoi, am verificat datele criptate prin berReader. Am crezut că datele criptate au o lungime de 16 octeți, deoarece lungimea textului simplu este $15$. Cu toate acestea, lungimea rezultatului este $32$ octeți.

Deci, am tastat:

openssl enc -aes-256-cbc -in simplu -out enc -k 123 ,pentru a obține date criptate.

Apoi, am verificat lungimea datelor criptate $16$ octeți în datele de ieșire.

Va dau poze cu rezultatul:

De ce dimensiunea datelor criptate cms este de 32 de octeți?

În plus, atașez imaginea că lungimea textului simplu este de 13 octeți. Dimensiunea datelor criptate este de 16 octeți.

AES este un cifru bloc și are nevoie de un cod adecvat mod de operare precum CBC, CTR și așa mai departe.

În timp ce modurile de streaming precum CFB, OFB și CTR nu necesită umplutură, modul de operare CBC și ECB necesită umplutură.

În modul CBC, umplutura obișnuită este PKCS#7 căptușeală. Pentru criptarea CBC mesajul este împărțit în blocuri de 128 de biți și umplutura este aplicată în ultimul bloc. Pot exista două cazuri;

1. Mesajul a pierdut câțiva octeți; în acest caz, lasă $n$ este numărul de octeți lipsă, apoi numărul $n$ e adăugat $n$ ori ca un octet.

   [Message Bytes ][01] // 1 octet lipsește
   [Octeți de mesaj ][0202] // 2 octeți lipsesc 
   [Octeți de mesaj][030303] // 3 octeți lipsesc
   ....
   [MB][0F0F0F...0F0F0F0F] // 15 octeți lipsesc
   

2. Mesajul este multiplu de 16 octeți, asta înseamnă că ultimul bloc este plin. În acest caz, pentru a distinge acest caz de primul caz, adăugăm un nou bloc plin de 10s. Prin urmare, putem avea reversul căptușelii. Se poate vedea motivul dacă ultimul bloc are 01 ca ultimul octet. Este umplutura sau nu? Deci adăugând 01 înlătură această ambiguitate.

Cele de mai sus pot explica de ce un mesaj devine un multiplu de 16 octeți după criptarea corectă CBC.

În cazul întrebării, 15 octeți pot deveni 16 octeți prin adăugare 01 ca ultimul octet. Dar restul de 16 octeți?

Modul de operare CBC are nevoie de 16 octeți Aleatoriu și imprevizibile Vector de inițializare (IV) pentru a obține securitatea Ind-CPA.

IV este una dintre cerințele pentru decriptarea primului bloc, altul decât cheia ( cheie, IV și $C_0$ este necesară);

$$P_0 = \operatorname{AES-DEC}(key,C_0) \oplus IV$$

Prin urmare, IV-ul trebuie adăugat/transferat, de asemenea. În practica obișnuită, IV este atașat textului cifrat.

Ce se întâmplă dacă IV nu este stocat/transferat? Ei bine, vei pierde doar primul bloc al mesajului, restul poate fi decriptat corect din moment ce;

$$P_i = \operatorname{AES-DEC}(key,C_i) \oplus C_{i-1}, \quad i \geq 1$$

CMS

The CMS necesită

Câmpul de parametri AlgorithmIdentifier TREBUIE să fie prezent și câmpul parametri TREBUIE să conțină un AES-IV:

  AES-IV ::= ȘIR DE OCTET (DIMENSIUNE(16))

IV este stocat în AlgorithmIdentifier câmp, nu în Conținut criptat La fel de Dave a scris că este -binar problema.

• Opțiunea OpenSSL -k

  IV și Key sunt derivate din metoda de derivare a cheii folosind parola utilizatorului și sare aleatoare de 8 octeți. IV-ul nu este predat.

  OpenSSL scoate mai întâi cuvântul magic Sărat__ apoi sare de 8 octeți apoi textul cifrat în fișier. Acum dimensiunea de ieșire este dimensiunea ta magică + dimensiunea sării + dimensiunea textului cifrat