Umplutura PKCS#7 este definită în rfc5652#section-6.3
Unii algoritmi de criptare a conținutului presupun că lungimea intrării este a
multiplu de k octeți, unde k este mai mare decât unu. Pentru așa
algoritmi, intrarea va fi completată la capătul final cu
k-(lth mod k) octeți toți având valoarea k-(lth mod k), unde lth este
lungimea intrării. Cu alte cuvinte, intrarea este completată la
finalul final cu unul dintre următoarele șiruri de caractere:
01 -- dacă al-lea mod k = k-1
02 02 -- dacă lth mod k = k-2
.
.
.
k k ... k k -- dacă al-lea mod k = 0
După cum putem vedea, octeții de umplutură pot conține o serie de01,02,...,
sau,16
pentru un cifru bloc de 16 octeți. În timp ce citesc
Am văzut că au dat un exemplu ca;
Al doilea bloc conține cei 9 octeți HMAC rămași și 7
octeți de umplutură 0x06
, vezi Figura 1. Rețineți că criptatorul poate alege, de asemenea, padding mai lung și adăuga 23, 39, ... sau 247 de octeți de umplutură (în timp ce setează valoarea octeților de umplutură în consecință).
Aceasta nu este umplutură PKCS#7. Deci, m-am uitat la TLS 1.2 RFC 5246 și vezi aproape același model;
Dacă lungimea căptușelii ar fi minimul necesar, 6, căptușeala ar fi 6
octeți, fiecare conținând valoarea 6. Astfel, ultimii 8 octeți ai
GenericBlockCipher înainte de criptarea blocului ar fi xx 06 06 06 06 06
06 06, unde xx este ultimul octet al MAC.
Pentru a fi compatibil cu umplutura PKCS#7, cele de mai sus ar trebui să fie ( nu a putut vedea un erată)
Dacă lungimea căptușelii ar fi minimă necesară, 7, căptușeala ar fi 7
octeți, fiecare conținând valoarea 7. Astfel, ultimii 8 octeți ai
GenericBlockCipher înainte de criptarea blocului ar fi xx 07 07 07 07 07
07 07, unde xx este ultimul octet al MAC.
și articolul are și acolo o greșeală.
Din câte știu, aceste două resurse sunt incorecte. Există ceva ce mi-a omis despre diferitele modele/utilizări ale regulilor de umplutură PKCS#7?