Rembourrage - algorithme de chiffrement

Question

Je suis en train d’écrire une implémentation de l’algorithme de chiffrement XXTEA qui fonctionne sur les " flux " ;, c’est-à-dire qu’elle peut être utilisée comme suit: crypt mykey < monfichier > sortie.

L'une des conditions préalables est qu'il n'a pas du tout accès au fichier (il ne lit qu'un bloc de taille fixe jusqu'à la recherche d'un fichier EOF). L'algorithme a besoin que les octets de données soient multiples de 4, il est donc nécessaire d'ajouter un remplissage.

Pour le texte brut, une bonne solution consiste à compléter avec des valeurs NULL, et dans le déchiffrement, ignorez simplement les valeurs NULL, mais la même stratégie ne peut pas être utilisée pour les flux binaires (pouvant contenir des valeurs NULL incorporées).

J'ai lu les solutions courantes, telles que le remplissage avec le nombre de caractères manquants (s'il manque 3 caractères, ajoutez 3, 3, 3 à la fin), etc., mais je me demande: il existe une solution plus élégante. ?

Answer 1

En lisant la question, il semble que l’aspect sécurité de cette question soit discutable. Autrement dit, vous avez une API qui attend en entrée un multiple de 4 octets, que vous n’avez pas toujours.

Il est dangereux d’ajouter jusqu’à 3 octets sur tout flux binaire si vous ne pouvez pas garantir que le flux binaire n’a pas d’importance. L'ajout de 0 à la fin d'un fichier exe n'a pas d'importance, car les fichiers exe ont des en-têtes spécifiant les tailles pertinentes de tous les bits restants. L'ajout de 0 à la fin d'un fichier pcx aurait pour effet de le casser, car les fichiers pcx ont un en-tête qui commence un nombre d'octets spécifique à partir de la fin du fichier.

Vous n'avez donc vraiment pas le choix - vous ne pouvez pas choisir d'octets de remplissage magiques garantis qui ne se produiront jamais naturellement à la fin d'un flux binaire: vous devez toujours en ajouter au moins un dword supplémentaire d’informations décrivant les octets de remplissage utilisés.

Answer 2

Lire: http://msdn.microsoft .com / fr-us / library / system.security.cryptography.paddingmode.aspx

Il contient une liste des méthodes de remplissage courantes, telles que:

PKCS7 - La chaîne de remplissage PKCS # 7 consiste en une séquence d'octets, chacun étant égal au nombre total d'octets de remplissage ajoutés.

La chaîne de remplissage ANSIX923 consiste en une séquence d'octets remplis de zéros avant la longueur.

La chaîne de remplissage ISO10126 est constituée de données aléatoires avant la longueur.

Exemples:

Données brutes: 01 01 01 01 01

PKCS # 7: 01 01 01 01 01 01 03 03 03

ANSIX923 01 01 01 01 01 00 00 03

ISO10126: 01 01 01 01 01 CD A9 03

Answer 3

Renseignez-vous sur le vol de texte crypté . C'est sans doute beaucoup plus élégant que le remplissage en texte brut. En outre, je suggérerais d’utiliser une taille de bloc supérieure à 4 octets - 64 bits est probablement le strict minimum.

Strictement parlant, la cryptographie à faire soi-même est une idée dangereuse. Il est difficile de battre des algorithmes que toute la communauté crypto a essayé et n'a pas réussi à casser. Amusez-vous et pensez à lire ceci , ou du moins à partir de

Answer 4

En fait, je m'attendrais à ce qu'un bon chiffre chiffré ne nécessite aucun remplissage. RC4, par exemple, ne nécessite aucun remplissage et constitue un très puissant code de flux. Toutefois, il peut être attaqué si l'attaquant peut fournir différentes données choisies à la routine de chiffrement, qui utilise toujours la même clé et a également accès aux données chiffrées. Le choix des bonnes données d'entrée et l'analyse des données de sortie peuvent être utilisés pour restaurer la clé de chiffrement, sans attaque brutale. mais à part ça, le RC4 est très sécurisé.

Si elle a besoin d'être complétée, il n'y a pas de code de flux IMHO. Comme si vous composiez un multiple de 4 octets ou un multiple de 16 octets, quelle est la différence énorme? Et s'il est composé d'un multiple de 16 octets, vous pouvez utiliser à peu près n'importe quel bloc de chiffrement. En fait, votre chiffre est un bloc, il fonctionne avec des blocs de 4 octets. C'était un code de flux sur un système où chaque & "Symbole &"; correspond à 4 octets (par exemple, lors du cryptage de texte UTF-32, auquel cas les données seront toujours un multiple de 4, il n’y aura donc jamais de bourrage).