l'entropie n'augmente pas avec le nombre d'itérations.
Personne n’a prétendu le contraire.
les itérations ne servent alors qu'à cacher la misère. à donner aux données une apparence de nombre aléatoire
Pas du tout. On ne compte pas sur le nombre d‘itérations pour « donner aux données une apparence de nombre aléatoire » (ça voudrait dire quoi d’ailleurs ?).
Le nombre d’itérations ne sert pas à augmenter l’entropie, mais à compenser la faible entropie de départ en rendant plus difficile de réaliser une attaque par force brute.
Parce que le problème des mots de passe, c’est justement qu’ils sont vulnérables aux attaques par force brute (contrairement à une suite d’octets aléatoires provenant d’un RNG). Un mot de passe de 8 caractères alphanumériques par exemple, c’est au maximum (26 + 26 + 10)8 possibilités. C‘est largement à la portée des machines modernes, qui peuvent calculer plusieurs milliards de condensats SHA2-256 par seconde.
(Et encore, là je ne tiens pas compte de plusieurs facteurs qui rendent les attaques encore plus faisables, comme le fait que les humains sont notooirement très mauvais quand il s’agit de choisir un mot de passe – ce que les craqueurs de mots de passe savent très bien exploiter, notamment en faisant des attaques par dictionnaire plutôt que d’énumérer bêtement toutes les combinaisons de caractères possibles.)
Du coup, puisque le nombre de possibilités à tester est relativement faible (suffisamment faible pour être brute-forceable), on augmente le nombre d’itérations pour que chaque possibilité à tester prenne plus longtemps. Avec 1 000 itérations, une machine capable de calculer un milliard de condensats SHA2-256 par seconde ne peut plus tester qu’un million de possibilités par seconde.
C’est à ça, et uniquement à ça, que sert le nombre d’itérations.
il vaut mieux mettre en place un système d'accumulation d'entropie et ne faire qu'un hash en sortie plutôt que le système décrit dans ce document..
C’est quoi que tu ne comprends pas dans le fait qu’ici l’entrée de la fonction est un mot de passe entré par l’utilisateur ?
Tu ne peux pas ajouter de l’entropie à un mot de passe ! Ta fonction de dérivation doit se débrouiller avec le mot de passe choisi par l’utilisateur.
je maintiens que la fonction SHA256 est cryptographiquement assez bonne pour générer en une passe.
Lorsque l‘entrée est une suite d’octets (pseudo-)aléatoire (par exemple une graine en provenance directe d‘un RNG), oui. Lorsque l’entrée est un mot de passe, catégoriquement pas.
Le problème n’est pas que SHA2-256 n’est pas « cryptographiquement assez bonne » (elle l’est), le problème est qu’elle est rapide.
le document me laisse un peu songeur étant donné qu'il conseille l'utilisation du SHA-1 comme PRF qui ne doit plus être utilisé dans les systèmes modernes.
L’absence de résistance aux collisions n’a absoluement aucune importance ici.
Fun fact : la principale raison pour laquelle on veut se débarasser complètement de SHA-1 est que les cryptologues ont en assez de devoir expliquer constamment que non, toutes les applications cryptographiques des fonctions de condensation n’ont pas forcément besoin de la propriété de résistance aux collisions.
[^] # Re: Cryptographie fragile
Posté par gouttegd . En réponse à la dépêche QGestpass logiciel de gestion de mots de passe et de sites web. Évalué à 10.
Personne n’a prétendu le contraire.
Pas du tout. On ne compte pas sur le nombre d‘itérations pour « donner aux données une apparence de nombre aléatoire » (ça voudrait dire quoi d’ailleurs ?).
Le nombre d’itérations ne sert pas à augmenter l’entropie, mais à compenser la faible entropie de départ en rendant plus difficile de réaliser une attaque par force brute.
Parce que le problème des mots de passe, c’est justement qu’ils sont vulnérables aux attaques par force brute (contrairement à une suite d’octets aléatoires provenant d’un RNG). Un mot de passe de 8 caractères alphanumériques par exemple, c’est au maximum (26 + 26 + 10)8 possibilités. C‘est largement à la portée des machines modernes, qui peuvent calculer plusieurs milliards de condensats SHA2-256 par seconde.
(Et encore, là je ne tiens pas compte de plusieurs facteurs qui rendent les attaques encore plus faisables, comme le fait que les humains sont notooirement très mauvais quand il s’agit de choisir un mot de passe – ce que les craqueurs de mots de passe savent très bien exploiter, notamment en faisant des attaques par dictionnaire plutôt que d’énumérer bêtement toutes les combinaisons de caractères possibles.)
Du coup, puisque le nombre de possibilités à tester est relativement faible (suffisamment faible pour être brute-forceable), on augmente le nombre d’itérations pour que chaque possibilité à tester prenne plus longtemps. Avec 1 000 itérations, une machine capable de calculer un milliard de condensats SHA2-256 par seconde ne peut plus tester qu’un million de possibilités par seconde.
C’est à ça, et uniquement à ça, que sert le nombre d’itérations.
C’est quoi que tu ne comprends pas dans le fait qu’ici l’entrée de la fonction est un mot de passe entré par l’utilisateur ?
Tu ne peux pas ajouter de l’entropie à un mot de passe ! Ta fonction de dérivation doit se débrouiller avec le mot de passe choisi par l’utilisateur.
Lorsque l‘entrée est une suite d’octets (pseudo-)aléatoire (par exemple une graine en provenance directe d‘un RNG), oui. Lorsque l’entrée est un mot de passe, catégoriquement pas.
Le problème n’est pas que SHA2-256 n’est pas « cryptographiquement assez bonne » (elle l’est), le problème est qu’elle est rapide.
L’absence de résistance aux collisions n’a absoluement aucune importance ici.
Fun fact : la principale raison pour laquelle on veut se débarasser complètement de SHA-1 est que les cryptologues ont en assez de devoir expliquer constamment que non, toutes les applications cryptographiques des fonctions de condensation n’ont pas forcément besoin de la propriété de résistance aux collisions.