Pourquoi les fichiers de hachage sont-ils toujours différents dans les fichiers de sortie openssl aes-256-cbc?

Question

J'ai essayé de chiffrer le fichier en utilisant cette commande:

openssl enc -aes-256-cbc -in $infile -out $outfile -pass file:$keyfile

Pour le même fichier d'entrée, Pourquoi les fichiers de sortie ont des hachages différents.

Gilles · Accepted Answer

CBC nécessite un IV : le tout premier bloc de données doit être aléatoire. Il est envoyé avec les données afin que le destinataire dispose de ce dont il a besoin pour déchiffrer le message. La IV pour CBC devrait être niformément aléatoire et imprévisible . La commande openssl enc crée un IV avec 8 octets fixes et 8 octets aléatoires (il doit s'agir de 16 octets aléatoires). Lorsque vous chiffrez le même message deux fois, le IV change. (Il existe une option -nosalt pour utiliser un IV fixe, ce qui est encore pire pour la sécurité et ne devrait pas être fait à moins que le mot de passe ait été généré de manière aléatoire pour un seul message.)

Tous les modes de cryptage non interrompus ont un IV ou un équivalent, de sorte que le cryptage du même message à deux reprises donne lieu à des cryptages différents. Cela est au moins nécessaire pour qu'un adversaire ne puisse pas détecter si deux messages cryptés ont le même texte en clair. La répétition de l'IV pour des messages distincts peut ouvrir d'autres attaques. Par exemple, avec CBC, un préfixe commun à deux messages est visible dans le texte chiffré si le IV est réutilisé. Si jamais vous trouvez que chiffrer le même message deux fois conduit au même texte crypté, quelque chose est cassé.

N'utilisez pas la commande openssl pour un travail sérieux . Il ne s'agit que d'une vitrine des fonctions de la bibliothèque, et il est mal conçu, même pour cela. Comme nous l'avons vu, la commande enc ne fait pas les choses en toute sécurité car son IV n'est pas aussi aléatoire qu'il le devrait. Un problème plus grave est la façon dont la clé est dérivée du mot de passe: openssl enc utilise un seul tour de MD5 , ce qui est mauvais - dériver une clé à partir d'un mot de passe doit utiliser une fonction intrinsèquement lente ( un fonction d’étirement de clé ) pour ralentir les tentatives de craquage par force brutale où l’attaquant utilise des mots de passe probables (mots du dictionnaire, 1337 variantes, etc.).

Le principal outil de chiffrement au niveau utilisateur est GPG , disponible sous Ubuntu dans le gnupg ou gnupg paquet. Pour chiffrer un fichier avec un mot de passe, utilisez

gpg -c filename

Vous serez invité à entrer le mot de passe. Le fichier crypté sera stocké dans filename.gpg. Pour déchiffrer, exécutez gpg filename.gpg et entrez la phrase secrète.

Vincent Yu · Answer

(Je pense que vous avez accidentellement ajouté l'option de décryptage -d dans la commande de votre question.)

Les fichiers cryptés diffèrent en raison du caractère aléatoire 64 bits cryptographique qu'OpenSSL génère et inclut dans chaque fichier crypté par défaut. Cela peut être désactivé avec l'option -nosalt, mais comme l'indique la documentation contenue dans man enc de OpenSSL, il s'agit généralement d'une très mauvaise idée:

L'option -salt devrait TOUJOURS être utilisée si la clé est dérivée d'un mot de passe, sauf si vous souhaitez une compatibilité avec les versions précédentes d'OpenSSL et de SSLeay.

Sans l'option -salt, il est possible d'effectuer des attaques de dictionnaire efficaces sur le mot de passe et d'attaquer les données cryptées en flux. La raison en est que sans le sel, le même mot de passe génère toujours la même clé de cryptage. Lorsque le sel est utilisé, les huit premiers octets des données cryptées sont réservés au sel: ils sont générés aléatoirement lors du cryptage d'un fichier et lus à partir du fichier crypté lors de son décryptage.