L'uso di un MAC per la crittografia elimina la necessità di riempire PKCS7 con questa classe?

Secondo la documentazione di PHP, l'output Serialize() 'può contenere byte nulli e deve essere gestito di conseguenza. Quindi, a meno che non ci sia una garanzia (che non vedo) che un byte null non può essere alla fine dei dati serializzati, allora sì, è decisamente consigliabile utilizzare il padding PKCS # 7.

Nel caso dell'autore di quel bit di codice, è in realtà assicurato che i dati non finiranno in un byte null, perché sta aggiungendo il MAC al testo in chiaro prima della crittografia, in un MAC-then-encrypt schema. Questo è sbagliato. Non farlo. Questo è ciò che porta ad imbottire attacchi oracle come POODLE. È necessario garantire l'integrità del testo cifrato prima di decodificare, il che significa invece encrypt-then-MAC.

Inoltre, la chiave HMAC sembra essere strettamente correlata alla chiave di crittografia. Questo non è l'ideale La chiave HMAC e la chiave di crittografia non devono essere correlate.

In terzo luogo, il calcolo HMAC deve essere eseguito in tempo costante per prevenire attacchi temporali. Le tecniche per farlo in PHP sono trattate in un commento su hash_hmac .

Esistono requisiti separati per l'esecuzione della modalità di riempimento deterministico e la fornitura di un tag di autenticazione.

Il padding è richiesto per le modalità di funzionamento ECB e CBC. Queste modalità gestiscono solo i messaggi che sono N volte la dimensione del blocco in lunghezza. Il padding PHP standard non è deterministico se il messaggio può terminare con byte con valore zero.

Il tag di autenticazione (fornito da un HMAC, ad esempio) è necessario per proteggere l'integrità del messaggio e mostrare che è stato inviato dal mittente previsto (autenticità). Se l'integrità del testo cifrato non è convalidata, qualsiasi attaccante può inviare o alterare messaggi (attacchi attivi o attacchi man-in-the-middle). Ciò potrebbe persino violare la riservatezza se è possibile intercettare gli attacchi di Oracle.

Quindi dovresti provare a utilizzare il padding anche compatibile con PKCS # 7 se fornisci un HMAC e specialmente se i tuoi messaggi potrebbero terminare con zero. Il commento sulle "prevedibili posizioni di testo in chiaro" può essere ignorato; dovresti aspettarti che gli attaccanti conoscano una certa quantità di informazioni sul testo in chiaro (come la dimensione del testo in chiaro). Questo è OK fintanto che l'integrità e la riservatezza sono state salvaguardate.

Si noti che l'autore dell'articolo sembra acquisire un bel po 'di educazione dai commenti. Il fatto che l'autore confonda Rijndael con una dimensione del blocco di 256 bit ( MCRYPT_RIJNDAEL_256 in PHP) con AES mostra che l'autore non sa molto della crittografia.

Non dovresti fidarti di questo codice. È necessario comprendere la crittografia prima di utilizzare una libreria o uno snippet di codice. Almeno prova e usa un formato contenitore noto se non sei sicuro. Chiunque può applicare AES. Almeno il 90% di StackOverflow (dove questa domanda è stata pubblicata prima) tuttavia lo applica in modo errato.