Lungimile de ieșire AES nu sunt întotdeauna un multiplu de 16

Am o soluție C# care criptează o grămadă de bucăți mici de date folosind AES.

        //Așa configurez obiectul Aes
        var aes = Aes.Create();
        aes.Mode = CipherMode.CBC;
        aes.KeySize = 256;
        aes.Padding = PaddingMode.PKCS7;

Apoi scriu octeții de text cifrat brut în coloanele SQL Server VARBINARY.

Interogând lungimea acestor coloane de text cifrat VARBINARY, mă așteptam să fie întotdeauna un multiplu de 16 octeți. Cu toate acestea, nu pare să fie cazul aici.

Am încercat să citesc despre asta online și singurele întrebări pe care le-am găsit sunt de ce textul cifrat AES este completat cu blocuri de până la 16 octeți, așa că m-am gândit să întreb aici despre întrebarea inversă.

Note:

• Am testat decriptarea unuia dintre aceste texte cifrate de dimensiuni ciudate și a funcționat bine, astfel încât textul cifrat nu este incorect.
• Am observat că nu se întâmplă des, într-o singură cursă s-a întâmplat de 19 ori din 5.828.
• Când se întâmplă, este întotdeauna unul cu unul (31 în loc de 32, 767 în loc de 768 etc..)

M-am gândit că poate standardul AES ar putea trunchia octeții de criptare care sunt exact zero (sau un alt număr binecunoscut) de la sfârșitul ieșirii, deoarece ar putea fi reconstruiți de către decriptor? Dar mi-ar plăcea clarificări.

Ai dreptate; AES-CBC standard (fără, să zicem, furtul de text cifrat) are o ieșire care este întotdeauna un multiplu de 16 octeți lungime.

O posibilitate care mi se pare că, dacă implementarea dvs. AES are o eroare, ar fi dacă ultimul octet s-ar întâmpla să fie 0x00, atunci nu l-ar scoate de fapt (și în direcția de decriptare, dacă textul cifrat ar fi scurt un octet, ar fi adăugați implicit un 0x00).

Dacă această ipoteză ar fi cazul, atunci în cele 5.828 de cazuri de testare, ne-am aștepta să vedem ca ultimul octet de text cifrat să fie 0 (și, prin urmare, trunchiat) de 22,8 ori; De 19 ori se încadrează într-o abatere standard și deci este plauzibil...