Y a-t-il une perte d'entropie en hachant une clé aléatoire de N bits pour produire un hachage de N bits?
J'ai lu le code suivant:
dd if=/dev/urandom bs=16 count=1 2>/dev/null | md5sum
Apparemment, ce code a été utilisé comme une astuce pour produire une clé de chaîne hexadécimale à partir d'une valeur pseudo-aléatoire binaire de 128 bits.
Quelqu'un ici a affirmé que cela est intrinsèquement non sécurisé car il transmet une valeur aléatoire cryptographiquement sécurisée via une "fonction de hachage non sécurisée".
De mon côté, je dirais que les défauts de collision dans md5 ne sont pas pertinents ici puisque l'entrée et la sortie de la fonction de hachage ont la même taille. Et donc, la sortie de la fonction de hachage est aussi aléatoire que son entrée.
Quelle est votre opinion à ce sujet? Le hachage d'une clé aléatoire de N bits pour produire un hachage de N bits modifie-t-il le caractère aléatoire de la clé?
Le hachage est un processus déterministe qui signifie qu'il ne peut jamais augmenter le caractère aléatoire. Mais bien sûr, cela peut diminuer le caractère aléatoire: si vous hachez une valeur aléatoire de 200 bits avec certains algorithmes de hachage qui ne produisent que 160 bits (comme SHA-1), alors bien sûr, la valeur résultante ne peut jamais avoir un caractère aléatoire de 200 bits.
Mais tant que le nombre de bits d'entrée est nettement inférieur à la taille de sortie du hachage, il ne réduira pas le caractère aléatoire, à condition qu'un hachage cryptographique soit utilisé. Si la taille d'entrée est exactement la même que la taille d'entrée comme dans votre exemple, le caractère aléatoire résultant n'est probablement pas diminué de manière significative lors de l'utilisation d'un hachage cryptographique. Et vous avez raison, la résistance aux collisions n'a pas d'importance pour cela.
dd if=/dev/urandom bs=16 count=1 2>/dev/null | md5sum
Ceci est garanti pour perdre une certaine entropie, mais pas beaucoup. La difficulté à attaquer MD5 ne suggère pas directement le montant de la perte, mais nous indique simplement qu'elle n'est pas nulle.
Si je retombe sur une construction naïve, je trouve que la perte d'entropie peut être calculée à partir de la probabilité en point fixe de 63,21%. ce qui à son tour implique que moins d'un bit d'entropie a été perdu. J'oublie combien on dit que vous avez réellement besoin, mais je sais que 122 bits de véritable entropie sont suffisants.
D'un autre côté, qu'essayez-vous d'accomplir ici? dd if=/dev/urandom bs=16 count=1 est suffisant en soi. Il ne sert à rien d'essayer d'utiliser md5 pour défendre kekkak-f contre la faiblesse.
Si vous ressentez vraiment le besoin de faire quelque chose ici, créez une clé secrète d'application 128 bits, générez-la en temps d'installation directement à partir de /dev/random (pas urandom), et xor dans le flux depuis /dev/urandom. Mais je ne vois aucune raison de lever le petit doigt pour le faire.