2.4. Padding (for Encryption) (Padding per crittografia)

Due fattori principali richiedono o motivano l'uso del campo Padding.

Se viene impiegato un algoritmo di crittografia che richiede che il testo in chiaro sia un multiplo di un certo numero di byte, ad esempio la dimensione del blocco di un cifrario a blocchi, il campo Padding viene utilizzato per riempire il testo in chiaro (costituito dai campi Payload Data, Padding, Pad Length e Next Header) alla dimensione richiesta dall'algoritmo.
Il padding può anche essere richiesto, indipendentemente dai requisiti dell'algoritmo di crittografia, per garantire che il testo cifrato risultante termini su un limite di 4 byte. Nello specifico, i campi Pad Length e Next Header devono essere allineati a destra all'interno di una parola di 4 byte, come illustrato nelle figure del formato del pacchetto ESP sopra, per garantire che il campo ICV (se presente) sia allineato su un limite di 4 byte.

Il padding oltre a quello richiesto per l'algoritmo o le ragioni di allineamento citate sopra potrebbe essere utilizzato per nascondere la lunghezza effettiva del payload, a supporto del TFC. Tuttavia, il campo Padding descritto è troppo limitato per essere efficace per il TFC e quindi non dovrebbe essere utilizzato per tale scopo. Invece, il meccanismo separato descritto di seguito (vedere sezione 2.7) dovrebbe essere utilizzato quando è richiesto il TFC.

Il mittente PUÒ aggiungere da 0 a 255 byte di padding. L'inclusione del campo Padding in un pacchetto ESP è opzionale, soggetta ai requisiti sopra indicati, ma tutte le implementazioni DEVONO supportare la generazione e il consumo di padding.

Allo scopo di garantire che i bit da crittografare siano un multiplo della dimensione del blocco dell'algoritmo (primo punto sopra), il calcolo del padding si applica ai Payload Data escludendo qualsiasi IV, ma includendo i campi del trailer ESP. Se una modalità algoritmica combinata richiede la trasmissione del SPI e del Sequence Number per effettuare l'integrità, ad esempio la replica del SPI e del Sequence Number nei Payload Data, allora le versioni replicate di questi elementi di dati e qualsiasi dato equivalente all'ICV associato sono inclusi nel calcolo della lunghezza del pad. (Se è selezionata l'opzione ESN, anche i 32 bit di ordine superiore dell'ESN entrerebbero nel calcolo, se l'algoritmo in modalità combinata richiede la loro trasmissione per l'integrità.)
Allo scopo di garantire che l'ICV sia allineato su un limite di 4 byte (secondo punto sopra), il calcolo del padding si applica ai Payload Data inclusi l'IV, i campi Pad Length e Next Header. Se viene utilizzato un algoritmo in modalità combinata, qualsiasi dato replicato e dato equivalente all'ICV sono inclusi nei Payload Data coperti dal calcolo del padding.

Se sono necessari byte di Padding ma l'algoritmo di crittografia non specifica il contenuto del padding, allora DEVE essere utilizzata la seguente elaborazione predefinita. I byte di Padding sono inizializzati con una serie di valori interi (senza segno, 1 byte). Il primo byte di padding aggiunto al testo in chiaro è numerato 1, con i byte di padding successivi che costituiscono una sequenza monotonicamente crescente: 1, 2, 3, .... Quando viene impiegato questo schema di padding, il ricevitore DOVREBBE ispezionare il campo Padding. (Questo schema è stato selezionato per la sua relativa semplicità, facilità di implementazione nell'hardware e perché offre una protezione limitata contro certe forme di attacchi "taglia e incolla" in assenza di altre misure di integrità, se il ricevitore controlla i valori di padding alla decrittografia.)

Se un algoritmo di crittografia o in modalità combinata impone vincoli sui valori dei byte utilizzati per il padding, essi DEVONO essere specificati dall'RFC che definisce come l'algoritmo viene impiegato con ESP. Se l'algoritmo richiede il controllo dei valori dei byte utilizzati per il padding, anche questo DEVE essere specificato in tale RFC.