- La clé et l'IV sont dérivées du mot de passe que vous spécifiez, à l'aide d'un algorithme spécifique à OpenSSL dont l'équipe OpenSSL n'est pas fière. Ils le conservent pour des raisons de compatibilité ascendante, mais ils recommandent d'utiliser de meilleures fonctions de dérivation de clé basées sur le mot de passe, telles que PBKDF2 de PKCS.
L'algorithme de dérivation de clé d'OpenSSL se trouve dans la fonction EVP_BytesToKey(3) .
Clé :
- la clé à utiliser : elle doit être représentée par une chaîne composée uniquement de chiffres hexadécimaux.
IV :
En cryptographie, un vecteur d'initialisation (IV) ou une variable de départ (SV)[1] est une entrée de taille fixe dans une primitive cryptographique qui est qui doit généralement être aléatoire ou pseudo-aléatoire.
L'IV est donc une donnée supplémentaire utilisée pour crypter le fichier. Il s'agit de no la clé (je suppose qu'il s'agit d'une question de terminologie).
2 Un sel est un supplément (préfixe) à la clé que vous spécifiez. (voir Wikipedia (en anglais) . Il est donc impossible d'utiliser des tables arc-en-ciel ou des tables de hachage précalculées sur votre clé. Le sel est généralement stocké en clair.
3 La sortie sera binaire et contiendra probablement des caractères non imprimables. Votre émulateur de terminal essaiera de rendre ces valeurs d'octets sous forme de caractères imprimables avec son codage de caractères et sa police de caractères par défaut, mais elles ressembleront probablement à du "texte poubelle" et ne seront pas sûres pour le copier/coller, le FTP ou le courrier électronique.
4 Pour déchiffrer un texte crypté, vous avez besoin de la clé et de l'IV. Si vous n'avez pas l'un de ces éléments, ou les deux, et que ceux qui vous manquent ont été dérivés du mot de passe, alors si vous avez le mot de passe, vous pouvez dériver à nouveau la clé et/ou l'IV manquantes à partir du mot de passe. Vous n'avez pas besoin du sel, car vous l'avez déjà ; il est placé au début du texte crypté. Le sel n'est pas vraiment un secret, c'est juste un moyen de déjouer les tables de hachage et les tables arc-en-ciel précalculées.
5 Telle que définie dans EVP_BytesToKey(3) Si vous utilisez un mot de passe de "1" et de --nosalt les 16 premiers octets de votre clé seront :
md5( D_0 || password || salt)
(à noter que dans ce contexte, || signifie concaténation, et non logique or )
ce qui équivaut à
md5 ( `null` || "1" || `null`)
ce qui équivaut à
md5("1")
Ce qui s'avère être
0xc4ca4238a0b923820dcc509a6f75849b
Cette valeur est ce que la page de manuel appelle D_1 .
Les octets restants de la clé et de l'IV sont générés de la manière suivante :
md5( D_1 || password || salt)
ce qui équivaut à
md5( 0xC4CA4238A0B923820DCC509A6F75849B || "1" || `null` )
ce qui équivaut à
md5( 0xC4CA4238A0B923820DCC509A6F75849B31 )
(notez que le "1" ASCII devient 0x31 concaténé à la fin de l'expression D_1 valeur)
qui s'avère être :
0x7976c7161415c830816dd4068a1d9a52
c'est-à-dire ce que la page de manuel appelle D_2.
La clé n'a besoin que de 8 octets de plus que D_1 déjà prouvé, il prend donc les 8 premiers octets de D_2 et devient :
Key: C4CA4238A0B923820DCC509A6F75849B7976c7161415c830
L'IV n'a besoin que de 8 octets, et comme il y a 8 octets inutilisés dans D_2, ils deviennent l'IV :
IV: 816dd4068a1d9a52
Voici une ligne de commande pour générer D_1, les 16 premiers octets de la clé (compte tenu de votre exemple de mot de passe "1" et de --nosalt ) :
echo -n "1" | openssl md5
Voici une ligne de commande pour générer D_2, les 8 octets restants de la clé, ainsi que les 8 octets de l'IV (toujours en fonction des données d'entrée de votre exemple) :
echo -n "$(echo -n "1" | openssl md5 -binary)1" | md5
Cette opération consiste à prendre la sortie de D_1 (en veillant à la conserver en binaire plutôt que de la convertir en chiffres hexadécimaux codés en ASCII), à y ajouter "1" (0x31) et à prendre la fonction md5 de cela.
