0.56. Générer un nombre aléatoire ne peut pas être confié à un ordinateur. Quel que soit son travail la valeur aléatoire est complètement prédictible car est produite par un algorithme. Par contre, il est possible de créer un générateur aléatoire indépendant de l'ordinateur. Il suffit d'alimenter un transistore entre la base et le collecteur avec l'émetteur en l'air. Le résultat est la production d'un bruit blanc. Il suffit ensuite de filtrer ce bruit blanc avec un signal qui s'y superpose. La valeur du signal carré (porteuse) représente 1 quand il est bien rempli par le bruit blanc, zéro quand il n'est pas assez rempli. Ensuite il suffit de compter les signaux par paquet de 8 pour en faire un octet.
Fun fact, pour faire du vrai random, Cloudflare utilise des images prises en temps reel d'un mur rempli de Lava Lamps. Le mouvement interne de la lampe est completement chaotique, et la transformation des pixels de l'image en valeurs permet d'assurer un chiffrement reelement aleatoire !
Bonne vidéo, mais il y a de plus en plus de fautes de frappe ou d'orthographe sur tes vidéos, ça ne fait pas très pro, il faudrait prendre plus de temps pour se relire
Quand il s'agit de manipuler des données sécurisées, Il est évident qu'il faut utiliser des fonctions de chiffrement avancé que dispose le langage qu'on utilise au lieu d'utiliser la fonction classique random. Cette dernière peut-être utilisée pour des animations et des rendus sans enjeux sécuritaire (expérience UX)
En fait, pour créer un nombre complètement aléatoire, il faudrait un composant électronique sur la carte mère qui capterait le "bruit" environnemental. Un peu comme les mouchetis sur les tv avant la tnt lorsqu'on ne captait pas de chaine. Ca serait complètement aléatoire !.
Je me souviens d'un article sur la façon dont Cloudflare générait ses nombres aléatoires en se basant sur des photos prises à intervalles réguliers de l'état d'un mur entier de lampes à lave, de doubles pendules ou encore de la désintégration d'une boulette d'uranium.
C'est pas la fonction qui est dangereuse, c'est les développeurs qui sont incompétents. C'est même écrit dans la doc officielle que c'est du *pseudo*-aléatoire : "The Math.random() method returns a **pseudo-random** number". N'importe qui qui fait du dev de façon un peu sérieuse sait que le pseudo-aléatoire n'a rien à voir avec un "aléatoire cryptographique"...
bonjour comment allez-vous ? je suis un étudiant en informatique et je suis à la recherche d'un grand frère pour suivre mon évolution. Merci de me répondre.
Ce qui est dangereux c'est pas d'utiliser un générateur pseudo aléatoire, mais de faire confiance au client. (Vous me direz que si on utilise le générateur côté serveur, ça reste moyen selon l'algorithme utilisé)
Je ne comprends pas pourquoi il est impossible de créer un générateur de nombres aléatoires si on utilise les multiples capteurs présents sur un ordinateur, en introduisant une ou plusieurs nouvelles graines dans l'algorithme principal à chaque nouveau nombre généré. Est-ce que je n'ai pas compris le problème?
En général il peut être couteux en temps (enfin couteux comparé aux instructions traité en quelques nanosecondes tout du moins) de faire des mesures sur l'environnement pour générer des nombres aléatoires. C'est là que servent les algorithmes générateurs de nombre pseudo aléatoire, on ne fait qu'une mesure pour générer la seed et après on peut générer plusieurs valeurs (il faut voir que si on parle de mesure sur l'environnement, il faut bien attendre que l'environnement aie suffisamment évolué entre deux mesures au risque que les valeur successives soient corrélés ou calculable l'une par rapport à l'autre).
@@capeitalist6963 Si on prend la dixième décimale de la mesure d'un capteur quel qu'il soit (son, chaleur, éclairage, tension, etc) c'est totalement imprévisible. Je ne connais pas d'applications qui réclament des quantités tellement gigantesques de nombres aléatoires que leur cout de production soit un problème... Bref, je ne comprends toujours pas où se trouve la difficulté dans la production de valeurs aléatoires, si ce n'est évidemment dans l'utilisation imprudente de générateurs peu fiables.
@@Ctrl_Alt_Sup Quand bien même on prend la dixième décimal, le capteur a "un temps de réaction" entre chaque mise à jour et absolument rien ne garantit que deux valeurs proches ne soient pas liés. Pour générer de manière fiable une graine il faut plusieurs sources de bruit certaines sont plus rapides à mesurer que d'autres mais dans tout les cas pour générer plusieurs valeur aléatoire il semble qu'il est préférable de multiplier les sources et d'utiliser un algorithme de génération de nombre pseudo aléatoire plutôt que de se restreindre à l'utilisation de source dont il est facile de faire plusieurs mesures rapidement.
Ah cool, merci ! Je vais le partager avec des gens car je n'arrivais pas à leur expliquer de pourquoi faut utiliser des random cryptographique plutôt que le joujou random 😅
Tant que tu utilise le nombre avant pour générer le nombre suivant c'est mort... Il faut n'utilise que le seed melangé et ne pas réinjecter le nombre retourner... Par exemple le nombre avant le mod... Avec un seed avec suffisamment de bit (256 min)...
Je ne comprends pas bien, le risque n'existe que pour des programmes écrits par des personnes particulièrement incompétentes. Pour les langages de programmation dignes de ce nom, Ils me semblait que les fonctions de génération de nombres aléatoires utilisaient l'heure machine, et plus particulièrement exploitaient les valeurs des microsecondes, rendant ainsi impossible de prévoir la valeur quasi-aléatoire obtenue. Un scolaire bricoleur qui joue avec des petits processeurs Arduino 8 bits est même capable de faire cela en 10 minutes !
On ne peut pas se baser sur l'heure pour générer des nombres aléatoires cryptographique sûr. Admettons que l'ont génère un nombre aléatoire à partir de l'heure en microseconde, et que j'essaie de deviner ce nombre. Supposons que je sache quel jour vous avez généré ce nombre (ce qui pourrait facilement se déduire d'une analyse de l'activité d'un compte par exemple). Comme il y a 1 000 000 de microsecondes en une secondes, 3 600 secondes en une heure et 24 heures en une journée alors il n'y a que 86,4 milliards de micro seconde en une journée, autrement dit moins de 87 milliards de seed possible, avec un ordinateur il est trés rapide de tester toutes les graines possibles et donc de trouver le nombre que vous avez généré et ceux même si ce dernier est composé de plusieurs milliers de chiffres.
Moi l'idée qui me vient en tête c'est de créer plusieurs générateurs de nombres différents (en centaine) et t'en appelles un à chaque fois de façon différente aléatoirement à l'appel, comme ca on élargie le déterminisme même si ca reste déterministe.
@@samuel310597 oui, mais le but serait de toujours changé de générateurs. Duc oup ca élargit le champs des possibles. Mais effectivement ca ne sort pas du cadre déterministes
Si un seul des générateurs est compromis cela fait que 1% des nombres générés l'est aussi... En cryptographie c'est beaucoup trop élevé. Ce qui serait plus pertinent par contre c'est de mélanger le résultat des 100 générateurs de sortent que si 1 seul sur les 100 n'est pas compromis alors le résultat reste sûr (ça se fait facilement avec une porte XOR).
Merci pour ton travail. Mais du coup ne peut-on pas déjà simplement faire un nombre d'appel aléatoire à Math.random() ? Car si on a une série de 5 aléatoires (donc en partant du seed, l'occurence 1, puis 2, puis 3, puis 4, puis 5)... tu peux deviner le 6ème. Mais si on double chaque appel (on trash le premier retour), on aura alors les occurences 2, 4, 6, 8 et 10 de ta chaine pseudo aléatoire avec la seed... donc on pourra plus deviner avec la méthode conventionnelle (sauf à savoir l'astuce)... et si encore mieux, si on fait un Math.floor(Math.random()*10) (pour avoir un entier entre 0 et 9)... et on "boucle" le Math.random() pour "trash" et récupérer que le dernier, ça commence à être chaud à péter non ?
Ton nombre d'appel aléatoire est lui même soumis à du pseudo aléatoire, et de façon générale faire de la cybersécurité par l'obscurantisme (faire des étapes intermédiaires en espérant que le hacker ne comprenne pas) ça marche pas trop et ça se casse très vite (reverse, bruteforce et j'en passe)
@@Impact_t ou alors on démarre la série par une racine aléatoire en fonction de différentes entrées ou état du système (mouvement souris, tension et utilisation des CPU et GPU,...)
Y a des cons qui génère les nombres aléatoires côté client ? Ou isolé leurs avec un seed par connections ? Où on utilise une lib système qui utilise l'activité de la.machine pour mélanger le seed ?
Aujourd'hui on ne sait pas expliquer autrement que par l'aléatoire les mesures en physiques quantiques (la physique quantique en dehors de la mesure est elle par contre 100% déterministes et prévisibles).
Ca complexifie le problème mais ca ne le résoud pas vraiment si ? Pour un nombre donné en entrée, on va garder le même nombre en sortie. Il faudrait faire jouer un élément physique, comme le temps d'attente entre une instruction au processeur et la réponse. Il faudra bien plus de temps pour générer des nombres aléatoires ceci dit
Ca depend de ou tu place la limite de hasard tout est predictible avec suffisamment d'informations le trucs c'est juste de faire en sorte de devoir connaître trop d'informations pour le rendre predictible humainement parlant
Super contenu, comme toujours! Un peu hors sujet, mais je voulais demander: Mon portefeuille OKX contient des USDT et j'ai la phrase de récupération. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). Comment puis-je les transférer vers Binance?
0.56. Générer un nombre aléatoire ne peut pas être confié à un ordinateur. Quel que soit son travail la valeur aléatoire est complètement prédictible car est produite par un algorithme.
Par contre, il est possible de créer un générateur aléatoire indépendant de l'ordinateur.
Il suffit d'alimenter un transistore entre la base et le collecteur avec l'émetteur en l'air.
Le résultat est la production d'un bruit blanc. Il suffit ensuite de filtrer ce bruit blanc avec un signal qui s'y superpose. La valeur du signal carré (porteuse) représente 1 quand il est bien rempli par le bruit blanc, zéro quand il n'est pas assez rempli.
Ensuite il suffit de compter les signaux par paquet de 8 pour en faire un octet.
On peut aussi utiliser les propriétés aléatoires de la mécanique quantique
Fun fact, pour faire du vrai random, Cloudflare utilise des images prises en temps reel d'un mur rempli de Lava Lamps. Le mouvement interne de la lampe est completement chaotique, et la transformation des pixels de l'image en valeurs permet d'assurer un chiffrement reelement aleatoire !
Ce n'est pas la fonction qui est dangereuse, mais de l'utiliser pour ce pour quoi elle n'est pas prévue.
Très juste.
Bonne vidéo, mais il y a de plus en plus de fautes de frappe ou d'orthographe sur tes vidéos, ça ne fait pas très pro, il faudrait prendre plus de temps pour se relire
Hors sujet
Je m'en suis même pas aperçu, c'est une vidéo informative pas un séminaire
Mdr on s’en fou des fautes! Big pouce sa7bi pour tes vidéos
La quantité et leur visibilité est gênante
C'est important pour toi ? 😑
Quand il s'agit de manipuler des données sécurisées, Il est évident qu'il faut utiliser des fonctions de chiffrement avancé que dispose le langage qu'on utilise au lieu d'utiliser la fonction classique random. Cette dernière peut-être utilisée pour des animations et des rendus sans enjeux sécuritaire (expérience UX)
En fait, pour créer un nombre complètement aléatoire, il faudrait un composant électronique sur la carte mère qui capterait le "bruit" environnemental. Un peu comme les mouchetis sur les tv avant la tnt lorsqu'on ne captait pas de chaine. Ca serait complètement aléatoire !.
Je me souviens d'un article sur la façon dont Cloudflare générait ses nombres aléatoires en se basant sur des photos prises à intervalles réguliers de l'état d'un mur entier de lampes à lave, de doubles pendules ou encore de la désintégration d'une boulette d'uranium.
@@NiamorH Tu troll c'est pas possible 😂😂
@@mwlulud2995 non il ne troll pas cherche cloudflare lava lamp
@@mwlulud2995 th-cam.com/video/1cUUfMeOijg/w-d-xo.html
@@mwlulud2995 th-cam.com/video/lydhprdvVmc/w-d-xo.html
Hyper intéressant, merci. Comment tant de dev ont-ils pu se faire ainsi avoir ?
Sur certains navigateurs, il n'est point question de F12 pour afficher la console mais Ctrl + Maj + i
Très intéressant, merci.
Super, merci !
Je relaie !
C'est pas la fonction qui est dangereuse, c'est les développeurs qui sont incompétents. C'est même écrit dans la doc officielle que c'est du *pseudo*-aléatoire : "The Math.random() method returns a **pseudo-random** number". N'importe qui qui fait du dev de façon un peu sérieuse sait que le pseudo-aléatoire n'a rien à voir avec un "aléatoire cryptographique"...
bonjour comment allez-vous ?
je suis un étudiant en informatique et je suis à la recherche d'un grand frère pour suivre mon évolution. Merci de me répondre.
Ce qui est dangereux c'est pas d'utiliser un générateur pseudo aléatoire, mais de faire confiance au client. (Vous me direz que si on utilise le générateur côté serveur, ça reste moyen selon l'algorithme utilisé)
Intéressant, merci😊
Tres bonne vidéo apres en pratique les randoms sont souvent arrondi (coté serveur) donc c'est assez compliqué de les avoir pour le client
Effectue simplement une opération mathématique avec un modulo et c'est réglé. Ou simplement se baser sur des phénomènes physique (Ex : résistance).
Je ne comprends pas pourquoi il est impossible de créer un générateur de nombres aléatoires si on utilise les multiples capteurs présents sur un ordinateur, en introduisant une ou plusieurs nouvelles graines dans l'algorithme principal à chaque nouveau nombre généré.
Est-ce que je n'ai pas compris le problème?
Enfaite un generateur de nombre vraiment vraiment aléatoire est impossible on peut que simuler l aléatoire en cachant l algorithme
si un signal physique comme les bruits ambiants détectés par le micro est utilisé alors ce sera vraiment aléatoire.
En général il peut être couteux en temps (enfin couteux comparé aux instructions traité en quelques nanosecondes tout du moins) de faire des mesures sur l'environnement pour générer des nombres aléatoires. C'est là que servent les algorithmes générateurs de nombre pseudo aléatoire, on ne fait qu'une mesure pour générer la seed et après on peut générer plusieurs valeurs (il faut voir que si on parle de mesure sur l'environnement, il faut bien attendre que l'environnement aie suffisamment évolué entre deux mesures au risque que les valeur successives soient corrélés ou calculable l'une par rapport à l'autre).
@@capeitalist6963
Si on prend la dixième décimale de la mesure d'un capteur quel qu'il soit (son, chaleur, éclairage, tension, etc) c'est totalement imprévisible.
Je ne connais pas d'applications qui réclament des quantités tellement gigantesques de nombres aléatoires que leur cout de production soit un problème...
Bref, je ne comprends toujours pas où se trouve la difficulté dans la production de valeurs aléatoires, si ce n'est évidemment dans l'utilisation imprudente de générateurs peu fiables.
@@Ctrl_Alt_Sup Quand bien même on prend la dixième décimal, le capteur a "un temps de réaction" entre chaque mise à jour et absolument rien ne garantit que deux valeurs proches ne soient pas liés.
Pour générer de manière fiable une graine il faut plusieurs sources de bruit certaines sont plus rapides à mesurer que d'autres mais dans tout les cas pour générer plusieurs valeur aléatoire il semble qu'il est préférable de multiplier les sources et d'utiliser un algorithme de génération de nombre pseudo aléatoire plutôt que de se restreindre à l'utilisation de source dont il est facile de faire plusieurs mesures rapidement.
Très intéressant
Ah cool, merci !
Je vais le partager avec des gens car je n'arrivais pas à leur expliquer de pourquoi faut utiliser des random cryptographique plutôt que le joujou random 😅
Tant que tu utilise le nombre avant pour générer le nombre suivant c'est mort... Il faut n'utilise que le seed melangé et ne pas réinjecter le nombre retourner... Par exemple le nombre avant le mod... Avec un seed avec suffisamment de bit (256 min)...
Intéressant merci !
Salut où est le lien du github ? Il n'est pas dans la description
Toujours cool tes vidéos, merci. Allez pour pinailler: si tu pouvais dire _bibliothèque_ Open SSL et _bibliothèque_ BitcoinJS 😬
Un grand merci 🙏
Video très propre comme d'hab
Oulaaaaaa tu deviens excellent !!!
La vidéo me fait pensé à celle de micode sur le mec qui a créé le script pour le loto aux États Unis, trop chaud
Je ne comprends pas bien, le risque n'existe que pour des programmes écrits par des personnes particulièrement incompétentes. Pour les langages de programmation dignes de ce nom, Ils me semblait que les fonctions de génération de nombres aléatoires utilisaient l'heure machine, et plus particulièrement exploitaient les valeurs des microsecondes, rendant ainsi impossible de prévoir la valeur quasi-aléatoire obtenue. Un scolaire bricoleur qui joue avec des petits processeurs Arduino 8 bits est même capable de faire cela en 10 minutes !
On ne peut pas se baser sur l'heure pour générer des nombres aléatoires cryptographique sûr.
Admettons que l'ont génère un nombre aléatoire à partir de l'heure en microseconde, et que j'essaie de deviner ce nombre. Supposons que je sache quel jour vous avez généré ce nombre (ce qui pourrait facilement se déduire d'une analyse de l'activité d'un compte par exemple). Comme il y a 1 000 000 de microsecondes en une secondes, 3 600 secondes en une heure et 24 heures en une journée alors il n'y a que 86,4 milliards de micro seconde en une journée, autrement dit moins de 87 milliards de seed possible, avec un ordinateur il est trés rapide de tester toutes les graines possibles et donc de trouver le nombre que vous avez généré et ceux même si ce dernier est composé de plusieurs milliers de chiffres.
Qui ici peut m'expliquer les slover sat utiliser pour casser le sha256?
Il et ou le github ??
PwnFunction/v8-randomness-predictor
Moi l'idée qui me vient en tête c'est de créer plusieurs générateurs de nombres différents (en centaine) et t'en appelles un à chaque fois de façon différente aléatoirement à l'appel, comme ca on élargie le déterminisme même si ca reste déterministe.
Du coup ça reste encore déterministe vu que tu utilises un nombre aléatoire pour appeler tes générateurs
@@samuel310597 oui, mais le but serait de toujours changé de générateurs. Duc oup ca élargit le champs des possibles. Mais effectivement ca ne sort pas du cadre déterministes
J'ai eu la même idée que toi! Faut séparer la logique de la génération du nombre et l'appel à un nombre aléatoire
@@alexandrerodriguez8723 du coup il y a besoin de plusieurs logique de génération de nombre non ?
Si un seul des générateurs est compromis cela fait que 1% des nombres générés l'est aussi... En cryptographie c'est beaucoup trop élevé. Ce qui serait plus pertinent par contre c'est de mélanger le résultat des 100 générateurs de sortent que si 1 seul sur les 100 n'est pas compromis alors le résultat reste sûr (ça se fait facilement avec une porte XOR).
mais comment fonctionne les csprng ?
Je pense qu'il y a plusieurs facons différentes
Merci pour ton travail. Mais du coup ne peut-on pas déjà simplement faire un nombre d'appel aléatoire à Math.random() ? Car si on a une série de 5 aléatoires (donc en partant du seed, l'occurence 1, puis 2, puis 3, puis 4, puis 5)... tu peux deviner le 6ème. Mais si on double chaque appel (on trash le premier retour), on aura alors les occurences 2, 4, 6, 8 et 10 de ta chaine pseudo aléatoire avec la seed... donc on pourra plus deviner avec la méthode conventionnelle (sauf à savoir l'astuce)... et si encore mieux, si on fait un Math.floor(Math.random()*10) (pour avoir un entier entre 0 et 9)... et on "boucle" le Math.random() pour "trash" et récupérer que le dernier, ça commence à être chaud à péter non ?
Ton nombre d'appel aléatoire est lui même soumis à du pseudo aléatoire, et de façon générale faire de la cybersécurité par l'obscurantisme (faire des étapes intermédiaires en espérant que le hacker ne comprenne pas) ça marche pas trop et ça se casse très vite (reverse, bruteforce et j'en passe)
@@Impact_t ou alors on démarre la série par une racine aléatoire en fonction de différentes entrées ou état du système (mouvement souris, tension et utilisation des CPU et GPU,...)
@@FlyBy2507 C'est ce qui est utilisé (entre autres) par le /dev/urandom sur Linux
Y a des cons qui génère les nombres aléatoires côté client ? Ou isolé leurs avec un seed par connections ? Où on utilise une lib système qui utilise l'activité de la.machine pour mélanger le seed ?
Piton the french programming language.
En réalité le vrai hasard n'existe pas et meme à l'échelle de l'univers.
Si en mecanique quantique. En tout cas, dans l'état de nos connaissances, il y a de l'aléatoire dans l'infiniment petit
Aujourd'hui on ne sait pas expliquer autrement que par l'aléatoire les mesures en physiques quantiques (la physique quantique en dehors de la mesure est elle par contre 100% déterministes et prévisibles).
*prévisible et non *prédictible
Dangereuse même.
Ok mais maintenant imagine un nombre aléatoire avec 5 seed différent en input
Ca complexifie le problème mais ca ne le résoud pas vraiment si ?
Pour un nombre donné en entrée, on va garder le même nombre en sortie.
Il faudrait faire jouer un élément physique, comme le temps d'attente entre une instruction au processeur et la réponse.
Il faudra bien plus de temps pour générer des nombres aléatoires ceci dit
Sinon, le déterminisme n'empêche pas le hasard hein.
Ca depend de ou tu place la limite de hasard tout est predictible avec suffisamment d'informations le trucs c'est juste de faire en sorte de devoir connaître trop d'informations pour le rendre predictible humainement parlant
Super contenu, comme toujours! Un peu hors sujet, mais je voulais demander: Mon portefeuille OKX contient des USDT et j'ai la phrase de récupération. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). Comment puis-je les transférer vers Binance?
Ptdrrr
don't roll your own crypto
lets go