Can AES128 CBC utilise 0-padding?

Question

En raison de certaines limitations d'un client, ils remplissent le texte brut avec 0x00 avant de le transmettre à l'alogirhtm AES, au lieu du remplissage PKCS5/PKCS7 normal ou similaire.

Bien que ce soit faisable du côté de mon serveur, j'ai une question de savoir si l'utilisation de 0-padding fonctionne. Prenez un exemple que le texte brut se termine avec exactement le caractère 0-padding. Il est impossible pour le serveur de le distinguer.

Est-ce que le rembourrage 0 est l'une des méthodes de rembourrage acceptables et si oui, comment mon côté doit-il gérer correctement le rembourrage?

Merci d'avance.

Answer 1

Incertain de ce que l'on entend par "code ASCII 0", je suppose un octet avec la valeur 0x00? (Oui hex est toujours une chose) Voir Zero padding: Le remplissage de zéros peut ne pas être réversible si le fichier d'origine se termine par un ou plusieurs octets zéro, rendant impossible la distinction entre les octets de données en clair et les octets de remplissage.

Remplissage nul (0x00) peut fonctionner pour les données qui ne se termine pas par une valeur nulle, le texte ASCII est un exemple qui fonctionne. Le PHP mcrypt déprécié fait cela et le remplissage de null crée des problèmes d'interopérabilité. Donc: oui le remplissage nul fonctionne pour certaines données comme le texte mais échoue pour les données binaires.

Il est préférable de ne pas l'utiliser, le rembourrage PKCS # 7.PKCS # 5 est un rembourrage meilleur et plus généralement utilisé.