Français

Texte et outils du quotidien · Générateur de mots de passe

PRNG vs CSPRNG : d'où proviennent réellement les nombres aléatoires de votre navigateur

· Contexte

mots de passe crypto-web csprng

Octets de chiffrement du navigateur passant par l'échantillonnage de rejet vers un index d'un mot
Illustration vectorielle originale de ToolAcre

Explique la différence entre les générateurs pseudo-aléatoires et cryptographiquement sécurisés, comment les systèmes d'exploitation collectent l'entropie des événements matériels et comment ce caractère aléatoire atteint une page Web via l'API Web Crypto.

Les ordinateurs sont déterministes, alors d'où vient le hasard ? — le casse-tête de base derrière chaque générateur

JavaScript exécuté dans ToolAcre commence à une limite d'API. Il peut demander des octets à `crypto.getRandomValues`, observer si cet appel réussit et utiliser le tableau renvoyé. Il ne peut pas inspecter chaque événement physique, pool de noyau ou composant matériel qu'une plate-forme particulière peut utiliser en dessous. L’histoire de l’origine aléatoire du cahier d’exercices dépasse donc les preuves locales.

Une explication techniquement honnête commence là où commence l'observation. L'application sonde Web Crypto, le moteur l'encapsule et toutes les sélections consomment cette source. Les éléments internes spécifiques à la plate-forme ont besoin d'une documentation et d'audits sur la plate-forme, et non d'une instruction générique déduite du nom de la méthode du navigateur.

Le référentiel démarre au niveau de l'API du navigateur ; il n'audite pas les sources d'entropie physique

Les générateurs pseudo-aléatoires sont souvent décrits par des graines et un état reproductible, mais ce référentiel n'exige pas que les moteurs JavaScript partagent une conception Math.random. ToolAcre évite toute ambiguïté en interdisant entièrement l'API dans la production d'informations d'identification. Les analyses de sources appliquent cette garantie négative.

Les tests ont toujours besoin d'octets déterministes, ils injectent donc des objets exposant `getRandomValues` via un paramètre interne. Ces contrefaçons vivent dans un support de test et ne sont pas exportées en tant que mode de production prédéfini. La testabilité ne crée pas d'option utilisateur masquée pour les mots de passe répétables.

Math.random est interdit ici, sans revendiquer une conception PRNG universelle

Le produit utilise le « cryptographique » de manière ciblée : l'interface de navigateur requise est Web Crypto, et la génération échoue lorsqu'elle est absente ou inutilisable. L'application appelle la méthode lors de la détection au lieu de vérifier uniquement son type, détectant ainsi les environnements restreints où l'invocation est lancée.

Ce contrat ne promet pas de résistance à tout compromis d'état hypothétique ni ne certifie l'implémentation d'un navigateur. Il prouve quelle API la page demande et qu'aucune solution de secours plus faible n'est connectée à elle. L'intégrité de l'appareil reste en dehors du générateur.

La propriété cryptographique vérifiée est la source Web Crypto requise et le chemin de refus

Les événements de synchronisation, les instructions de processeur dédiées, les calendriers de réamorçage et les pools d'entropie du système d'exploitation se trouvent tous sous la surface de l'API Web. Aucun n'est affirmé ici car la source du package ne peut pas les vérifier. Un futur article spécifique à la plate-forme nécessiterait une documentation principale pour chaque environnement qu'il décrit.

L'omission renforce plutôt qu'affaiblit la revendication actuelle. ToolAcre peut dire exactement ce qu'il demande au navigateur de faire et comment il traite les octets. Il n'est pas nécessaire de prétendre que JavaScript peut auditer la chaîne d'entropie complète pour justifier le refus de Math.random.

Les détails des événements matériels et du pool de systèmes d'exploitation sont des affirmations d'implémentation que cette source ne prouve pas

`getRandomValues` remplit un `Uint8Array` dimensionné à partir de la limite exclusive demandée. `secureRandomInt` assemble ces octets sous la forme d'un nombre big-endian non signé, calcule la plus grande fenêtre d'acceptation divisible et ignore les valeurs du reste. La valeur acceptée est ensuite réduite à un indice.

Les mots, les délimiteurs, les caractères et les échanges aléatoires réutilisent tous ce chemin. Un seul point d'étranglement rend la chaîne navigateur-choix révisable et garantit que la correction de la réduction limitée affecte chaque mode de génération plutôt qu'un appelant oublié.

De getRandomValues à secureRandomInt : le chemin visible du navigateur vers l'index

Pour un pool de mots 7,776, la fonction sélectionne suffisamment d'octets pour représenter chaque index valide. Il forme un entier, rejette toute valeur égale ou supérieure à la limite calculée et renvoie le reste seulement après acceptation. `secureRandomChoice` utilise ce résultat pour lire un mot du tableau éligible.

L'index de production particulier est privé et ne doit pas être reproduit dans la documentation. Les tests déterministes alimentent à la place les octets de queue et de portée connus pour prouver le flux de contrôle. Cela retrace une sélection sans transformer une phrase générée en exemple public.

Exemple pratique : tracer des octets via un échantillonnage de rejet vers un index de liste

La conception matérielle du générateur de nombres aléatoires et les preuves cryptographiques formelles ne sont pas couvertes par le package. Les environnements d'exécution du serveur ou les applications natives ne le sont pas non plus. L'implémentation est un générateur de navigateur et ses garanties ne doivent pas être copiées sur des systèmes non liés.

Il ne traite pas non plus du stockage ou de l'utilisation ultérieure. Une valeur sélectionnée via Web Crypto peut toujours être exposée par réutilisation, phishing, historique du presse-papiers ou malware. Le choix de CSPRNG résout le problème de la source, pas tous les problèmes de gestion des informations d'identification.

Ce qu'il faut retenir : le générateur de mot de passe demande au générateur cryptographique du navigateur quelle est la bonne source pour un secret.

La chaîne d'action est courte : tester que Web Crypto fonctionne, refuser la génération lorsqu'elle ne fonctionne pas, remplir les octets, rejeter une queue inégale et mapper la valeur acceptée sur un index. ToolAcre rend chaque étape visible et teste les limites difficiles.

Examinez cette chaîne au lieu de vous fier à une vague étiquette « aléatoire ». Examinez ensuite le point de terminaison et la destination séparément. L’API cryptographique du navigateur est la source correcte de ce produit, mais le référentiel ne prétend pas certifier ce qui se trouve en dessous ni tout ce qui suit.