Texte et outils du quotidien · Générateur de mots de passe
Explication du biais modulo : choisir un mot aléatoire dans une liste sans biais
· Comment ça marche
mots de passe caractère aléatoire cryptographie
Montre pourquoi la « longueur de liste modulo de nombres aléatoires » favorise certains mots par rapport à d'autres lorsque la plage ne se divise pas uniformément, quelle est l'ampleur de l'asymétrie et comment l'échantillonnage par rejet le supprime.
Un dé juste et un raccourci injuste : pourquoi prendre un nombre aléatoire modulo 7,776 n'est pas la même chose que lancer des dés
Une source équitable peut toujours alimenter une routine de sélection injuste. Si un programme lit un entier et prend immédiatement le reste après division par une longueur de liste, certains indices reçoivent plus de valeurs source chaque fois que la plage source n'est pas exactement divisible par cette longueur. Le défaut réside dans l’étape de réduction, pas nécessairement dans les octets. ToolAcre évite ce raccourci avant de choisir un mot EFF.
Les dés physiques fournissent une comparaison intuitive uniquement lorsque les groupes de résultats complets correspondent uniformément. L'implémentation du navigateur a une plage brute différente, elle calcule donc une fenêtre d'acceptation pour la limite demandée. Cet article traite de ce mécanisme fourni plutôt que d'affirmer que les octets du navigateur reproduisent littéralement cinq dés. Les deux peuvent sélectionner des indices, mais leurs procédures et éléments probants sont distincts.
D'où vient le biais : une valeur 32 bits ne se divise pas uniformément en 7,776 buckets, donc les premiers mots ont une chance supplémentaire
Pour un octet et une limite de 100, la plage brute a 256 valeurs possibles. Deux groupes complets de 100 s'ajustent, laissant 56 valeurs. La réduction de chaque octet modulo 100 donne aux indices zéro à 55 trois préimages chacun, tandis que les indices 56 à 99 n'en reçoivent que deux. Les octets d'entrée peuvent être uniformes, mais la distribution de compartiments sélectionnée ne l'est pas.
Le commentaire d'implémentation dérive également le problème de plage finie correspondant pour une liste d'entrées 7,776 lorsque deux octets sont réduits directement. Ces chiffres proviennent des plages réelles indiquées dans la source, et non d'un taux d'attaque supposé. La question importante de l'examen est de savoir si les valeurs restantes sont utilisées, et non si le biais semble faible dans une poignée d'expressions générées.
Quelle est l'ampleur de l'effet : faible pour une large plage aléatoire, mais non nulle, et pourquoi le code cryptographique refuse de l'accepter
Les tests déterministes rendent observable la queue inégale. Les limites 3, 5, 7, 100 et 7,776 sont délibérément maladroites, tandis qu'une limite puissance de deux démontre le cas de non-rejet. Un autre contrôle statistique utilise la même source Web Crypto pour la fonction correcte et un assistant modulo naïf, de sorte que le test isole la stratégie de réduction plutôt que de blâmer la source d'entropie.
ToolAcre ne convertit pas ces contrôles de distribution en prédiction du temps de crack. Les biais réduisent l’uniformité, mais traduire cette réduction en coûts pour un attaquant particulier nécessite un modèle de menace complet. L'exigence d'ingénierie est plus claire : chaque index éligible doit avoir le même nombre de valeurs brutes acceptées, et le code peut exactement appliquer cela.
Les exemples de biais vérifiés dans les commentaires d'implémentation et les tests déterministes
`secureRandomInt` trouve le plus petit nombre d'octets entiers capable de représenter l'index valide le plus élevé. Il calcule la plage d'octets, soustrait le reste après division par la limite et appelle le résultat `limit`. Les valeurs inférieures à cette limite appartiennent à des groupes complets ; les valeurs égales ou supérieures à celui-ci sont ignorées avant que l'opération modulo ne soit autorisée à s'exécuter.
Un nouveau tirage au sort suit chaque refus. La boucle a un plafond fixe élevé, de sorte qu'une source injectée cassée ne peut pas suspendre la languette pour toujours ; après des valeurs hors limites répétées, il renvoie au lieu de renvoyer une réponse biaisée. Ce chemin d'échec fait partie de l'exactitude : refuser une source suspecte préserve la promesse qu'un index renvoyé provient de la fenêtre d'acceptation uniforme.
Alternatives : dessiner exactement suffisamment de bits et ignorer les valeurs hors plage, ou utiliser la fonction entière uniforme d'une bibliothèque
D'autres conceptions à nombres entiers uniformes sont possibles, mais elles ne correspondent pas au comportement de ce package et ne sont donc pas présentées comme des options ToolAcre interchangeables. Le moteur expose un chemin audité. `secureRandomChoice` valide que son entrée est un tableau non vide et délègue à `secureRandomInt(items.length)`, faisant de la sélection de mots un consommateur direct du contrat entier délimité.
Le générateur de mots de passe aléatoires utilise le même chemin pour les caractères, puis invoque un mélange Fisher-Yates piloté par des échanges limités sécurisés. Il n'utilise pas `sort` avec un comparateur aléatoire. Garder une primitive sous plusieurs fonctionnalités rend une révision de source plus facile : corrigez ou testez la réduction uniforme une fois, puis suivez ses appelants.
Les conceptions alternatives se trouvent en dehors de ce module ; le chemin expédié utilise un échantillonnage de rejet
Le test de régression lié-100 fournit chaque octet de queue de 200 à 255, puis un 42 final. Le code correct consomme tous les 56 octets rejetés et les réponses de 42. Un deuxième cas ciblé fournit 200 et 7 ; parce que 200 modulo 100 serait zéro, renvoyer 7 prouve que le premier octet a été rejeté plutôt que discrètement réduit.
Cet exemple concret est déterministe de par sa conception et ne contient aucune information d'identification. Les octets de production restent privés de l’appel du navigateur et ne sont pas enregistrés. La source de test est injectable uniquement afin que le comportement puisse être forcé à la limite ; le package public n'offre aucun mode de production prédéfini qui pourrait reproduire une phrase secrète générée.
Exemple pratique : 100 lié rejette l'octet 200 et accepte le 7 suivant
La réduction aléatoire à virgule flottante, les API uniformes spécifiques à la bibliothèque et les algorithmes de brassage non liés ne relèvent pas de cette implémentation. Leur évaluation nécessiterait leur source et leurs contrats. Le code de ToolAcre est basé sur des nombres entiers et explicitement délimité, donc l'ajout d'une enquête sur les alternatives brouillerait l'affirmation étroite que les tests prouvent réellement.
L'article ne déduit pas non plus qu'un mot de passe généré uniformément convient à chaque stratégie ou appareil. La sélection uniforme d’index répond à un mécanisme. Le stockage, la réutilisation, la gestion du presse-papiers, les logiciels malveillants et les contraintes de destination restent des questions distinctes, même lorsque chaque élément de la liste avait une chance égale d'être sélectionné.
Ce qu'il faut retenir : un générateur de phrase secrète doit choisir les mots de manière uniforme ; consultez les notes techniques de l'outil pour savoir comment le générateur de mots de passe le fait
Un générateur de phrase secrète ne doit pas favoriser les entrées anticipées simplement parce que sa plage brute laisse un reste. ToolAcre prend des octets de Web Crypto, rejette la queue incomplète et réduit uniquement les valeurs à l'intérieur de groupes complets de taille égale. Les tests imposent à la fois des limites de rejet et d'acceptation, de sorte que la réclamation n'est pas basée sur une inspection visuelle des résultats.
Lors de l'examen d'un code similaire, calculez la plage brute pour la largeur d'octet choisie, divisez-la par la limite demandée et recherchez un reste ignoré. Si aucune queue n'est rejetée, exiger une autre preuve d'homogénéité. La liste de mots peut être publique et la source cryptographique alors qu'une réduction imprudente introduit toujours un biais évitable.