J'étais l'un des implémenteurs de JScript et membre du comité ECMA du milieu à la fin des années 1990, donc je peux fournir une perspective historique ici.

La fonction JavaScript Math.random () est conçu pour renvoyer une valeur à virgule flottante entre 0 et 1. Il est bien connu (ou du moins devrait l'être) que la sortie n'est pas cryptographiquement sécurisée

Tout d'abord: la conception de nombreux RNG Les API sont horribles . Le fait que la classe .NET Random puisse être utilisée à mauvais escient de plusieurs manières pour produire de longues séquences du même nombre est horrible. Une API où la manière naturelle de l'utiliser est également la mauvaise est une API «gouffre»; nous voulons que nos API soient des puits de succès, où la manière naturelle et la bonne manière sont les mêmes.

Je pense qu'il est juste de dire que si nous savions alors ce que nous savons maintenant, l'API aléatoire JS serait différente. Même des choses simples comme changer le nom en "pseudo-aléatoire" aideraient, car comme vous le notez, dans certains cas, les détails d'implémentation sont importants. Au niveau architectural, il y a de bonnes raisons pour lesquelles vous voulez que random () soit une fabrique qui renvoie un objet représentant une séquence aléatoire ou pseudo-aléatoire, plutôt que de simplement renvoyer des nombres. Etc. Leçons apprises.

Deuxièmement, rappelons-nous quel était l'objectif fondamental de la conception de JS dans les années 1990. Faites danser le singe lorsque vous déplacez la souris . Nous pensions que les scripts d'expressions en ligne étaient normaux, nous pensions que les blocs de script de deux à dix lignes étaient courants, et l'idée que quelqu'un pourrait écrire cent lignes de script sur une page était vraiment très inhabituelle. Je me souviens de la première fois que j'ai vu un programme JS de dix mille lignes et ma première question aux personnes qui me demandaient de l'aide parce que c'était si lent par rapport à leur version C ++ était une version de "êtes-vous fou ?! 10KLOC JS ?! "

L'idée que n'importe qui aurait besoin de l'aléatoire cryptographique dans JS était tout aussi insensée. Vous avez besoin que vos mouvements de singe soient imprévisibles à la force cryptographique? Peu probable.

N'oubliez pas non plus que c'était au milieu des années 1990. Si vous n’êtes pas là, je peux vous dire que c’était un monde très différent d’aujourd’hui en ce qui concerne la cryptographie ... Voir export de cryptographie.

Je n'aurais même pas envisagé d'intégrer le caractère aléatoire de la force de la cryptographie à tout ce qui est livré avec le navigateur sans obtenir une énorme quantité de conseils juridiques de la part de l'équipe MSLegal. Je ne voulais pas toucher la crypto avec un poteau de dix pieds dans un monde où le code d'expédition était considéré comme l'exportation de munitions vers des ennemis de l'État . Cela semble fou du point de vue d'aujourd'hui, mais c'était le monde qui était.

pourquoi les navigateurs ne le remplacent-ils pas par un CSPRNG?

Les auteurs de navigateurs n'ont pas à fournir de raison pour NE PAS faire de changement. Les changements coûtent de l'argent et réduisent l'effort à de meilleurs changements; chaque changement a un coût d'opportunité énorme.

Plutôt, vous devez fournir un argument non seulement pourquoi faire le changement est une bonne idée, mais pourquoi c'est la meilleure utilisation possible de leur temps. Il s'agit d'un petit changement pour le prix.

Je comprends qu'il ne peut pas être redéfini en tant que CSPRNG car la norme ne donne explicitement aucune garantie d'aptitude à l'utilisation cryptographique, mais il ne semble pas y avoir d'inconvénient à le faire de toute façon

L'inconvénient est que les développeurs sont toujours dans une situation où ils ne peuvent pas savoir de manière fiable si leur caractère aléatoire est la force de la cryptographie ou pas, et peut encore plus facilement tomber dans le piège de s'appuyer sur une propriété qui n'est pas garantie par la norme. La modification proposée ne résout pas réellement le problème, qui est un problème de conception.

Parce qu'il existe en fait une alternative cryptographiquement sécurisée à Math.random():

window.crypto.getRandomValues ​​(typedArray)

Cela permet au développeur d'utiliser le bon outil pour le travail. Si vous voulez générer de jolies images ou des butins pour votre jeu, utilisez le rapide Math.random () . Lorsque vous avez besoin de numéros aléatoires sécurisés par cryptographie, utilisez la window.crypto , plus coûteuse.

JavaScript (JS) a été inventé en 1995.

1. Potentiellement illégal: la cryptographie était encore sous contrôle strict des exportations en 1995, donc un bon CSPRNG pourrait même ne pas avoir était légal de distribuer dans un navigateur.
2. Performance: historiquement, les CSPRNG (générateurs de nombres pseudo-aléatoires cryptographiquement sécurisés) sont beaucoup plus lents que les PRNG, alors pourquoi utiliser un CSPRNG par défaut?
3. Aucun état d'esprit de sécurité: en 1995, SSL venait d'être inventé. Pratiquement aucun serveur ne le supportait encore, Internet se composait de lignes téléphoniques et était utilisé pour les forums publics ( BBS) et MUDs. Le chiffrement était réservé aux agences de renseignement.
4. Pas besoin: les applications Web n'existaient pas encore, car JavaScript venait juste d'être inventé. Il a été conçu comme un langage interprété (donc lent) pour aider les pages à être plus dynamiques. Il n'aurait traversé l'esprit de personne d'utiliser un CSPRNG lent (et à peine existant) par défaut pour une fonction aléatoire.
5. Si peu besoin, en fait, qu'il n'y avait pas d'alternative: JavaScript n'avait même pas d'API généralement prise en charge pour un CSPRNG jusqu'en décembre 2013, donc une cryptographie appropriée dans les applications Web était à peine possible jusqu'à il y a quelques années.
6. Cohérence: plutôt que de changer une fonction existante pour avoir une signification différente, ils ont créé une nouvelle fonction avec un nom différent. Vous pouvez accéder au CSPRNG maintenant via crypto.getRandomValues.

En résumé: héritage, mais aussi rapidité et cohérence . Les PRNG non sécurisés sont encore beaucoup plus rapides car vous ne pouvez pas supposer que tout le matériel prend en charge AES ni dépendre de la disponibilité ou de la sécurité de RDRAND.

Personnellement, je pense qu'il est temps d'échanger toutes les fonctions aléatoires avec des CSPRNG et de renommer les fonctions plus rapides et non sécurisées en quelque chose comme fast_insecure_random () . Ils ne devraient être nécessaires que par des scientifiques ou d'autres personnes qui font des simulations qui nécessitent beaucoup de nombres aléatoires, mais où la prévisibilité du RNG n'est pas un problème. Mais pour une fonction avec deux décennies d'histoire, où une alternative n'existe que depuis quatre ans maintenant (en 2018), je peux comprendre pourquoi nous n'en sommes pas encore à ce point.

C'est trop long pour un commentaire.

Je pense qu'il y a une prémisse erronée dans votre question:

sur les ordinateurs modernes (et même pas si modernes), il serait trivial de produire des centaines de mégaoctets par seconde en utilisant ChaCha8 ou AES-CTR

Vous pensez à un navigateur de bureau sur une machine connectée au secteur ou à un ordinateur portable avec une grosse batterie honkin 10Ah.

Nous vivons dans un monde de plus en plus mobile, et si les appareils mobiles de nos jours sont assez puissants, ils ont deux contraintes importantes: la chaleur et l'autonomie de la batterie. Contrairement à un processeur de bureau qui peut facilement atteindre 100 ° C, vous ne pouvez pas brûler la main de l'utilisateur du smartphone. Et les batteries de téléphone ne contiennent généralement que peut-être 1/3 de la quantité d'un ordinateur portable (si vous avez de la chance). Il n'y a tout simplement aucune bonne raison d'ajouter la production de chaleur / consommation d'énergie supplémentaire si vous n'en avez pas besoin.

La principale raison est qu'il existe une alternative à Math.random () : voir la réponse de Philipp . Donc, quiconque a besoin d'une crypto forte peut l'avoir, et ceux qui n'en ont pas peuvent gagner du temps et de l'énergie (de la batterie).

Mais en supposant que vous ayez demandé, "pourquoi, même s'il existe une alternative plus les développeurs ne mettent pas à jour Math.random () de la même manière - c'est-à-dire ont fait de random () un dérivé de getRandomValues ​​() - afin de renforcer automatiquement un grand nombre d'applications? " - alors je ne pense pas que cela puisse vraiment répondre avec une quelconque confiance, sauf par les développeurs qui ont pris la décision (mise à jour: et comme le veut le destin, nous avons une telle réponse).

En principe - comme vous l'avez déjà dit - il n'y a pas de raison valable .

De plus, la plupart des équipes de développement ont un arriéré important de choses qui sont plus urgentes à faire ; et même un changement apparemment mineur comme celui-ci nécessite des tests, une régression et aller à l'encontre de la règle d'or " Si elle n'est pas enfreinte, ne la corrigez pas ", une forme plus forte du critère YAGNI.

Les nombres aléatoires et les bits cryptographiques sont des animaux complètement différents. Ils ne sont même pas utilisés dans le même but. Si vous voulez un nombre aléatoire uniformément réparti entre 0 et 42, vous voulez une distribution uniforme sans motif évident. Notez que si vous modifiez un plus grand nombre avec un plus petit, alors ce n'est pas exactement une distribution uniforme. Cet exemple est facile à voir pour un nombre aléatoire de 0 à 31 pris mod 27. 0 à 4 apparaît deux fois plus souvent que 5 à 31.

Jusqu'à ce que vous parliez de crypto-aléatoire, la notion d'entropie n'est pas ' t même discuté. Un peu d'entropie double l'espace de recherche pour deviner le nombre (pour l'utilisateur prévu des nombres).

Lorsque vous demandez des bits cryptographiques aléatoires, vous demandez N bits d'entropie. Il ne suffit pas d'avoir un modèle non évident, car si une fonction qui le génère est découverte (peu importe sa complexité), alors il y a en fait 0 bit d'entropie du point de vue de celui qui connaît cette fonction.

Un bon exemple de ceci est un générateur de nombres pseudo-aléatoires de type Fortuna. Vous cryptez un nombre 1 avec une clé pour le premier nombre aléatoire (où le bloc de chiffrement est un grand nombre), puis cryptez le numéro 2 avec une clé pour le deuxième nombre aléatoire, et ainsi de suite. En ce qui concerne l'utilisateur qui ne connaît pas la clé (de K bits) du chiffrement, un bloc de chiffrement parfait à N bits aura N bits d'entropie pour ce bloc.

Si vous étendez à un million de bits de données pseudo-aléatoires à partir de celui-ci, alors vous n'avez toujours que K bits d'entropie si vous continuez avec la même clé K. En d'autres termes: si vous aviez un livre de 1 million de bits dont vous savez qu'il a été généré avec un seul chiffre sous K, alors n'essayez pas de deviner tous les bits du flux de chiffrement. Tenez-vous-en à deviner la clé et générez le flux de chiffrement à partir de celle-ci.

Ainsi, un générateur de nombres aléatoires est souvent un chiffrement qui continue d'être réamorcé avec plus d'aléatoire, car il peut être atteint. Par comparaison, un simple générateur de nombres aléatoires [0,1] ne peut pas avoir plus d'entropie que le nombre de bits dans le nombre; et aura généralement une distribution étrange qui n'est pas exactement ce que vous voulez aussi. Crypto a besoin de centaines de bits, lorsque les nombres à virgule flottante ne sont que de 32 ou 64 bits, et l'algorithme lui-même enlève une grande partie de l'entropie .... en supposant que vous voulez quelque chose uniformément distribué à partir de [0..1], plutôt que de dire un représentation en virgule flottante composée de bits aléatoires. Je ne sais même pas quelle distribution cela aurait même.

Vous avez en quelque sorte répondu à la question vous-même:

la norme ne donne explicitement aucune garantie d'aptitude à l'utilisation cryptographique

Donc, plutôt que de changer l'implémentation, l'accent doit être mis sur la formation des développeurs à choisir le 'bon outil pour le travail' ™.

Compte tenu de cela, et de la charge technique liée à la modification de l'implémentation d'une fonction couramment utilisée, ainsi que du fait qu'il existe déjà des solutions spécifiques à ce problème (voir la réponse @Philipps), il n'y a aucune raison impérieuse de faire le changement.

La conception du langage de programmation doit prendre en compte de nombreux éléments. Les navigateurs sont très puissants et optimisent beaucoup javascript aujourd'hui. Mais lorsque vous considérez les systèmes embarqués, vous n'avez peut-être pas de bonne source d'aléa. Par exemple, il y a des microcontrôleurs exécutant un environnement nodeJS (comme).

Un tel microcontrôleur n'a pas de sources aléatoires qui garantissent des nombres aléatoires cryptographiquement sécurisés. Vous auriez donc besoin de connecter un appareil capable de fournir une entrée aléatoire à une broche pour pouvoir implémenter un langage de programmation qui offre de solides garanties sur les nombres aléatoires. Et vous auriez besoin de quelques connaissances pour construire un appareil qui offre suffisamment de caractère aléatoire et pour traiter les entrées de l'appareil de manière appropriée.

Comme d'autres, je ferais remarquer que Math.random () n'est pas cryptographiquement sécurisé car il n'est généralement pas nécessaire. Mais j'irais plus loin et soutiendrais qu'il n'est pas sage d'écrire un algorithme cryptographiquement sécurisé dans une spécification à moins que vous n'ayez une très bonne raison.

Que signifie être sécurisé cryptographiquement? Eh bien, il y a toujours la définition ennuyeuse de «personne ne sait encore comment le casser». Mais que se passe-t-il quand quelqu'un le casse? Si vous avez spécifié un CSPRNG, vous devez également inclure un moyen d'interroger quel algorithme est utilisé, ou de le faire autrement pour que l'utilisateur final puisse être certain de ce qu'il obtient.

Cela est également probable conduit à la nécessité de pouvoir prendre en charge plusieurs générateurs, de sorte que l'utilisateur puisse en sélectionner un en qui il a confiance. Cela ajoute une complexité énorme. Soudainement, une fonction d'une ligne dans une API est devenue une suite.

De plus, lorsque vous commencez à parler de crypto, vous commencez à parler d'essayer d'être sécurisé dans le générateur. Vous mentionnez l'utilisation d'AES pour générer des nombres aléatoires: votre implémentation AES doit-elle être immunisée contre les attaques de canaux secondaires? Lorsque vous écrivez une bibliothèque dans le but dédié de fournir des garanties cryptographiques, il n'est pas si déraisonnable d'avoir à poser cette question. Pour une spécification, cela pourrait être terriblement déraisonnable. L'immunité aux attaques par canaux secondaires est une chose très difficile à formuler dans le langage des spécifications.

Et qu'avez-vous accompli en le mettant dans une spécification? La plupart des utilisateurs de PRNG n'ont pas du tout besoin de garanties cryptographiques, vous avez donc simplement gaspillé des cycles de processeur pour eux. Ceux qui veulent des garanties cryptographiques vont probablement chercher une bibliothèque qui prend en charge la suite complète des fonctionnalités nécessaires pour être à l'aise avec une telle cryptogaphie, donc ils ne feront pas confiance à Math.random () de toute façon. Il ne reste plus que le groupe démographique que vous mentionnez: des personnes qui ont commis une erreur et ont utilisé un outil alors qu'elles ne le devraient pas. Eh bien, je peux vous dire par expérience que les principaux langages de programmation ne sont pas un endroit pour rechercher une API que vous ne pouvez pas utiliser de manière incorrecte par erreur. Ils sont pleins de phrases "si vous faites cela, c'est de votre faute".

Aussi, considérez ceci: si vous utilisez Math.random () et que vous assumez des garanties cryptographiques, Quelles sont les chances que vous fassiez une autre erreur de cryptographie fatale quelque part dans votre algorithme? Un CSPRNG Math.random () peut fournir un faux sentiment de sécurité, et nous pouvons trouver encore plus d'erreurs!

Tout le monde semble avoir manqué une petite nuance ici: les algorithmes cryptographiques exigent qu'un nombre soit mathématiquement et statistiquement aléatoire sur toutes les exécutions de l'algorithme. Cela signifie par exemple pendant un jeu ou une animation, que vous pourriez utiliser une suite de nombres aléatoires et ce serait parfaitement bien pour une "sorte de nombre aléatoire".

Cependant si ce nombre pouvait être manipulé ou prédit, par exemple un nombre aléatoire prédéfini (qui est le comportement par défaut des fonctions aléatoires de Windows), alors cette graine est en fait prévisible. Si je peux manipuler votre application pour redémarrer puis utiliser un nombre aléatoire prédéfini, je peux prédire quel nombre "aléatoire" vous choisirez. Si cela est possible, la cryptographie peut être vaincue. Une préoccupation secondaire peut également être que certains algorithmes nécessitent une distribution garantie des nombres sur tout le spectre, ce que certains générateurs aléatoires ne peuvent pas garantir.

Les générateurs de nombres aléatoires cryptographiques ont un grand ensemble d'entrées pour créer une entropie, par exemple mesurer le bruit de tir de l'entrée du microphone, les graduations de l'heure, la somme de contrôle des registres de bélier, les numéros de série, etc. Dans un sens cryptographique, les performances ne sont pas l'objectif, mais le "vrai" hasard.

Donc, en fonction de votre cas d'utilisation, vous voudrez peut-être une implémentation raisonnablement aléatoire et performante d'un nombre aléatoire, mais si vous faites une différence -hellman échange de clés vous avez besoin d'un algorithme cryptographiquement sécurisé.

Une autre considération que je n'ai vu personne mentionner (ou que j'ai simplement négligée) est que certaines utilisations de la fonction Math.random () dépendent en fait de la répétabilité lorsqu'elles sont initialisées de la même manière que les précédentes temps. Le changer maintenant casserait ces utilisations.