J'utilise /dev/random (et non urandom) pour créer des mots de passe sous
Débian.
J'ai lu que /dev/random exploite l'entropie de l'ordinateur pour la
génération de nombres "pseudo" aléatoires. Mais il n'est pas précisé de
quelles sources d'entropie il s'agit. Parmi ces sources, j'ai compris
qu'il y a les mouvements de la souris et les écritures disques. En
l'absence d'entropie, random ne génère plus de chiffre et bloque le
logiciel. Il suffit alors de bouger la souris pour faire avancer la
génération.
J'aimerais connaître les autres sources d'entropie afin d'éviter que mon
logiciel bloque de temps à autre en attendant que cette entropie soit
suffisante pour générer de nouveaux chiffres. Mon idée est de créer un
fork afin de générer l'entropie attendue par le générateur sans avoir à
bouger la souris.
"zeLittle" , dans le message <5c83f5c3$0$15166$, a écrit :
Le truc à comprendre, c'est que ceux qui travaillent avec des simulations nécessitant de grandes cohortes de nombres aléatoires, font tourner tous ces générateurs différents et regardent le temps maximum où la distribution de ces nombres (sensés rester aléatoires) reste normale.
Les gens qui travaillent avec des simulations ont des besoins d'aléa beaucoup plus faciles à satisfaire que la moindre banque ou n'importe qui travaillant dans la sécurité. Ils pourraient se contenter d'à peu près n'importe quel PRNG rapide de qualité quasi-cryptographique. Mais comme leur domaine d'expertise n'est pas l'informatique, ils prennent les lanternes pour des vessies et essaient de réinventer les choses plus près de leur domaine d'expertise.
La loterie suisse utilise un système physique complexe dont je ne me souviens pas de tous les détails, créant grosso-modo un tir de photons pseudo-aléatoires, sur un biface de verre diffractant le rayon (ajout d'une complexité).
Je te fais confiance sur les faits. Mais ce choix n'a aucune pertinence pour la sécurité, c'est uniquement du spectacle.
"zeLittle" , dans le message <5c83f5c3$0$15166$426a74cc@news.free.fr>, a
écrit :
Le truc à comprendre, c'est que ceux qui travaillent avec des simulations
nécessitant de grandes cohortes de nombres aléatoires, font tourner tous ces
générateurs différents et regardent le temps maximum où la distribution de
ces nombres (sensés rester aléatoires) reste normale.
Les gens qui travaillent avec des simulations ont des besoins d'aléa
beaucoup plus faciles à satisfaire que la moindre banque ou n'importe
qui travaillant dans la sécurité. Ils pourraient se contenter d'à peu
près n'importe quel PRNG rapide de qualité quasi-cryptographique. Mais
comme leur domaine d'expertise n'est pas l'informatique, ils prennent
les lanternes pour des vessies et essaient de réinventer les choses
plus près de leur domaine d'expertise.
La loterie suisse utilise un système physique complexe dont je ne me
souviens pas de tous les détails, créant grosso-modo un tir de photons
pseudo-aléatoires, sur un biface de verre diffractant le rayon (ajout d'une
complexité).
Je te fais confiance sur les faits. Mais ce choix n'a aucune pertinence
pour la sécurité, c'est uniquement du spectacle.
"zeLittle" , dans le message <5c83f5c3$0$15166$, a écrit :
Le truc à comprendre, c'est que ceux qui travaillent avec des simulations nécessitant de grandes cohortes de nombres aléatoires, font tourner tous ces générateurs différents et regardent le temps maximum où la distribution de ces nombres (sensés rester aléatoires) reste normale.
Les gens qui travaillent avec des simulations ont des besoins d'aléa beaucoup plus faciles à satisfaire que la moindre banque ou n'importe qui travaillant dans la sécurité. Ils pourraient se contenter d'à peu près n'importe quel PRNG rapide de qualité quasi-cryptographique. Mais comme leur domaine d'expertise n'est pas l'informatique, ils prennent les lanternes pour des vessies et essaient de réinventer les choses plus près de leur domaine d'expertise.
La loterie suisse utilise un système physique complexe dont je ne me souviens pas de tous les détails, créant grosso-modo un tir de photons pseudo-aléatoires, sur un biface de verre diffractant le rayon (ajout d'une complexité).
Je te fais confiance sur les faits. Mais ce choix n'a aucune pertinence pour la sécurité, c'est uniquement du spectacle.
Sylvain
Le 10/03/2019 à 11:09, Nicolas George a écrit :
Sylvain , dans le message <5c83cf3c$0$20307$, a écrit :
Mon idée était de lancer un processus en parallèle de la génération aléatoire afin de créer cette entropie
Va jusqu'au bout de ton raisonnement : comment ton processus s'y prendrait-il pour créer cette entropie ?
Comme a priori mon premier message n'est pas passé, je reposte. Comme /dev/random attend que l'entropie soit suffisante pour générer des nombre, et qu'en l'absence d'entropie il bloque le programme, mon idée est de lancer un processus en parallèle pour générer cette entropie. Actuellement, le simple fait de bouger la souris suffit pour faire avancer la génération, mais c'est assez lent, surtout pour des longueurs de 256 caractères. D'où mon post initial : qu'elles sont les sources d'entropie utilisées par /dev/random pour sa génération de nombres ? Pendant la génération, j'ai essayé avec succès de copier un très gros fichier vers une clé USB et d'entretenir un flux internet grâce à la fonction "une page au hasard" de Wikipédia. Mais c'est encore plus lent qu'en bougeant la souris... Sylvain
Le 10/03/2019 à 11:09, Nicolas George a écrit :
Sylvain , dans le message <5c83cf3c$0$20307$426a74cc@news.free.fr>, a
écrit :
Mon idée était de lancer un processus en parallèle de la génération
aléatoire afin de créer cette entropie
Va jusqu'au bout de ton raisonnement : comment ton processus s'y
prendrait-il pour créer cette entropie ?
Comme a priori mon premier message n'est pas passé, je reposte.
Comme /dev/random attend que l'entropie soit suffisante pour générer des
nombre, et qu'en l'absence d'entropie il bloque le programme, mon idée
est de lancer un processus en parallèle pour générer cette entropie.
Actuellement, le simple fait de bouger la souris suffit pour faire
avancer la génération, mais c'est assez lent, surtout pour des longueurs
de 256 caractères.
D'où mon post initial : qu'elles sont les sources d'entropie utilisées
par /dev/random pour sa génération de nombres ?
Pendant la génération, j'ai essayé avec succès de copier un très gros
fichier vers une clé USB et d'entretenir un flux internet grâce à la
fonction "une page au hasard" de Wikipédia. Mais c'est encore plus lent
qu'en bougeant la souris...
Sylvain , dans le message <5c83cf3c$0$20307$, a écrit :
Mon idée était de lancer un processus en parallèle de la génération aléatoire afin de créer cette entropie
Va jusqu'au bout de ton raisonnement : comment ton processus s'y prendrait-il pour créer cette entropie ?
Comme a priori mon premier message n'est pas passé, je reposte. Comme /dev/random attend que l'entropie soit suffisante pour générer des nombre, et qu'en l'absence d'entropie il bloque le programme, mon idée est de lancer un processus en parallèle pour générer cette entropie. Actuellement, le simple fait de bouger la souris suffit pour faire avancer la génération, mais c'est assez lent, surtout pour des longueurs de 256 caractères. D'où mon post initial : qu'elles sont les sources d'entropie utilisées par /dev/random pour sa génération de nombres ? Pendant la génération, j'ai essayé avec succès de copier un très gros fichier vers une clé USB et d'entretenir un flux internet grâce à la fonction "une page au hasard" de Wikipédia. Mais c'est encore plus lent qu'en bougeant la souris... Sylvain
Nicolas George
Sylvain , dans le message <5c85138d$0$20330$, a écrit :
Va jusqu'au bout de ton raisonnement : comment ton processus s'y prendrait-il pour créer cette entropie ?
Comme /dev/random attend que l'entropie soit suffisante pour générer des nombre, et qu'en l'absence d'entropie il bloque le programme, mon idée est de lancer un processus en parallèle pour générer cette entropie.
Et je te re-pose la question : comment ton processus ferait-il pour générer cette entropie, en pratique. Je peux la formuler encore plus précisément : imagine que tu aies une fonction : int give_entropy_to_kernel(char *data, size_t size); Ton processus l'appelle avec des données aléatoires dans data. Ma question est : où vas-tu chercher ces données aléatoires ?
Sylvain , dans le message <5c85138d$0$20330$426a74cc@news.free.fr>, a
écrit :
Va jusqu'au bout de ton raisonnement : comment ton processus s'y
prendrait-il pour créer cette entropie ?
Comme /dev/random attend que l'entropie soit suffisante pour générer des
nombre, et qu'en l'absence d'entropie il bloque le programme, mon idée
est de lancer un processus en parallèle pour générer cette entropie.
Et je te re-pose la question : comment ton processus ferait-il pour générer
cette entropie, en pratique.
Je peux la formuler encore plus précisément : imagine que tu aies une
fonction :
int give_entropy_to_kernel(char *data, size_t size);
Ton processus l'appelle avec des données aléatoires dans data. Ma question
est : où vas-tu chercher ces données aléatoires ?
Sylvain , dans le message <5c85138d$0$20330$, a écrit :
Va jusqu'au bout de ton raisonnement : comment ton processus s'y prendrait-il pour créer cette entropie ?
Comme /dev/random attend que l'entropie soit suffisante pour générer des nombre, et qu'en l'absence d'entropie il bloque le programme, mon idée est de lancer un processus en parallèle pour générer cette entropie.
Et je te re-pose la question : comment ton processus ferait-il pour générer cette entropie, en pratique. Je peux la formuler encore plus précisément : imagine que tu aies une fonction : int give_entropy_to_kernel(char *data, size_t size); Ton processus l'appelle avec des données aléatoires dans data. Ma question est : où vas-tu chercher ces données aléatoires ?
zeLittle
"Nicolas George" a écrit dans le message de groupe de discussion : 5c851f10$0$19258$
Et je te re-pose la question : comment ton processus ferait-il pour générer cette entropie, en pratique. Je peux la formuler encore plus précisément : imagine que tu aies une fonction : int give_entropy_to_kernel(char *data, size_t size); Ton processus l'appelle avec des données aléatoires dans data. Ma question est : où vas-tu chercher ces données aléatoires ?
Recherche Qwant => http://www.ressources-actuarielles.net/ext/isfa/1226.nsf/769998e0a65ea348c1257052003eb94f/fe1a778a8b27e299c1256d6100487209/$FILE/02.Planchet.Jacquemin.Simulation%201.pdf --> ça peut être purement algorithmique: - Rnd - Tore - De Moro - ... Cf. p. 18: grosso-modo, l'idée est de déstructurer une suite numérique, purement mathématique. Maintenant, ça marche le temps que ça marche: si on fait une boucle qu'on laisse tourner sur un PC générant des nombres, et si l'on analyse ensuite la variance de la distribution de ces nombres, il arrivera un moment où elle "penchera" franchement d'un côté, ou alors elle s'étirera à cause de la création de clusters dans des classes ventilées, ou se contractera autour d'un cluster naissant. D'où l'idée d'ajouter en sus, du hasard physique: bouger la souris: mais s'il faut trouver quelqu'un la bougeant tout le temps, ... De tout ce que j'ai entendu parlé, l'ajout d'un hasard *physique* - l'idée des oscillations, avec des effets retard ou avancé, basées sur des condensateurs, des diodes zener, ... - permettant d'ajouter une couche de distribution de hasard par dessus les déstructurations de générateurs mathématiques, en espérant créer une mixture finale qui retarde l'apparition de clusters d'ordre au sein des nombres sensés être distribués de façon homogène, est une bonne idée.
"Nicolas George" a écrit dans le message de groupe de discussion :
5c851f10$0$19258$426a34cc@news.free.fr...
Et je te re-pose la question : comment ton processus ferait-il pour
générer
cette entropie, en pratique.
Je peux la formuler encore plus précisément : imagine que tu aies une
fonction :
int give_entropy_to_kernel(char *data, size_t size);
Ton processus l'appelle avec des données aléatoires dans data. Ma question
est : où vas-tu chercher ces données aléatoires ?
--> ça peut être purement algorithmique:
- Rnd
- Tore
- De Moro
- ...
Cf. p. 18: grosso-modo, l'idée est de déstructurer une suite numérique,
purement mathématique.
Maintenant, ça marche le temps que ça marche: si on fait une boucle qu'on
laisse tourner sur un PC générant des nombres, et si l'on analyse ensuite la
variance de la distribution de ces nombres, il arrivera un moment où elle
"penchera" franchement d'un côté, ou alors elle s'étirera à cause de la
création de clusters dans des classes ventilées, ou se contractera autour
d'un cluster naissant.
D'où l'idée d'ajouter en sus, du hasard physique: bouger la souris: mais
s'il faut trouver quelqu'un la bougeant tout le temps, ...
De tout ce que j'ai entendu parlé, l'ajout d'un hasard *physique* - l'idée
des oscillations, avec des effets retard ou avancé, basées sur des
condensateurs, des diodes zener, ... - permettant d'ajouter une couche de
distribution de hasard par dessus les déstructurations de générateurs
mathématiques, en espérant créer une mixture finale qui retarde l'apparition
de clusters d'ordre au sein des nombres sensés être distribués de façon
homogène, est une bonne idée.
"Nicolas George" a écrit dans le message de groupe de discussion : 5c851f10$0$19258$
Et je te re-pose la question : comment ton processus ferait-il pour générer cette entropie, en pratique. Je peux la formuler encore plus précisément : imagine que tu aies une fonction : int give_entropy_to_kernel(char *data, size_t size); Ton processus l'appelle avec des données aléatoires dans data. Ma question est : où vas-tu chercher ces données aléatoires ?
Recherche Qwant => http://www.ressources-actuarielles.net/ext/isfa/1226.nsf/769998e0a65ea348c1257052003eb94f/fe1a778a8b27e299c1256d6100487209/$FILE/02.Planchet.Jacquemin.Simulation%201.pdf --> ça peut être purement algorithmique: - Rnd - Tore - De Moro - ... Cf. p. 18: grosso-modo, l'idée est de déstructurer une suite numérique, purement mathématique. Maintenant, ça marche le temps que ça marche: si on fait une boucle qu'on laisse tourner sur un PC générant des nombres, et si l'on analyse ensuite la variance de la distribution de ces nombres, il arrivera un moment où elle "penchera" franchement d'un côté, ou alors elle s'étirera à cause de la création de clusters dans des classes ventilées, ou se contractera autour d'un cluster naissant. D'où l'idée d'ajouter en sus, du hasard physique: bouger la souris: mais s'il faut trouver quelqu'un la bougeant tout le temps, ... De tout ce que j'ai entendu parlé, l'ajout d'un hasard *physique* - l'idée des oscillations, avec des effets retard ou avancé, basées sur des condensateurs, des diodes zener, ... - permettant d'ajouter une couche de distribution de hasard par dessus les déstructurations de générateurs mathématiques, en espérant créer une mixture finale qui retarde l'apparition de clusters d'ordre au sein des nombres sensés être distribués de façon homogène, est une bonne idée.
Nicolas George
"zeLittle" , dans le message <5c853001$0$19266$, a écrit :
--> ça peut être purement algorithmique:
Et devine : c'est ce que fait /dev/urandom. Et accessoirement, ça n'AJOUTE pas d'entropie, ça se contente de la diluer. Mais en informatique, l'entropie se dilue plus comme décrit par Banach-Tarski que par Hahnemann. C'est ce que j'essayais de te faire comprendre tout seul : s'il y avait moyen d'ajouter de l'entropie que tu puisses implémenter toi-même, il aurait déjà été implémenté dans le noyau.
"zeLittle" , dans le message <5c853001$0$19266$426a74cc@news.free.fr>, a
écrit :
--> ça peut être purement algorithmique:
Et devine : c'est ce que fait /dev/urandom.
Et accessoirement, ça n'AJOUTE pas d'entropie, ça se contente de la diluer.
Mais en informatique, l'entropie se dilue plus comme décrit par
Banach-Tarski que par Hahnemann.
C'est ce que j'essayais de te faire comprendre tout seul : s'il y avait
moyen d'ajouter de l'entropie que tu puisses implémenter toi-même, il aurait
déjà été implémenté dans le noyau.
"zeLittle" , dans le message <5c853001$0$19266$, a écrit :
--> ça peut être purement algorithmique:
Et devine : c'est ce que fait /dev/urandom. Et accessoirement, ça n'AJOUTE pas d'entropie, ça se contente de la diluer. Mais en informatique, l'entropie se dilue plus comme décrit par Banach-Tarski que par Hahnemann. C'est ce que j'essayais de te faire comprendre tout seul : s'il y avait moyen d'ajouter de l'entropie que tu puisses implémenter toi-même, il aurait déjà été implémenté dans le noyau.
zeLittle
"zeLittle" a écrit dans le message de groupe de discussion : 5c853001$0$19266$ "Nicolas George" a écrit dans le message de groupe de discussion : 5c851f10$0$19258$ [SNIP] ... avec des effets retard ou avancé, basées sur des condensateurs, des diodes zener, ... et des distorsions amplifiant ou diminuant le signal (que ce soit via I ou U, avec des transistors et tutti quanti)...[/SNIP]
"zeLittle" a écrit dans le message de groupe de discussion :
5c853001$0$19266$426a74cc@news.free.fr...
"Nicolas George" a écrit dans le message de groupe de discussion :
5c851f10$0$19258$426a34cc@news.free.fr...
[SNIP]
... avec des effets retard ou avancé, basées sur des
condensateurs, des diodes zener, ... et des distorsions amplifiant ou
diminuant le signal (que ce soit via I ou U, avec des transistors et tutti
quanti)...[/SNIP]
"zeLittle" a écrit dans le message de groupe de discussion : 5c853001$0$19266$ "Nicolas George" a écrit dans le message de groupe de discussion : 5c851f10$0$19258$ [SNIP] ... avec des effets retard ou avancé, basées sur des condensateurs, des diodes zener, ... et des distorsions amplifiant ou diminuant le signal (que ce soit via I ou U, avec des transistors et tutti quanti)...[/SNIP]
Nicolas George
Sylvain , dans le message <5c85138d$0$20330$, a écrit :
Comme a priori mon premier message n'est pas passé, je reposte.
Ce n'est pas qu'il n'est pas passé, c'est que tu l'as envoyé en privé, et j'ai pour politique de ne pas répondre aux réponses envoyées en privé, à moins que ce ne soit justifié et mentionné dans le mail. Sans compter que depuis hier on a des pannes de courant en salle des serveurs.
Sylvain , dans le message <5c85138d$0$20330$426a74cc@news.free.fr>, a
écrit :
Comme a priori mon premier message n'est pas passé, je reposte.
Ce n'est pas qu'il n'est pas passé, c'est que tu l'as envoyé en privé,
et j'ai pour politique de ne pas répondre aux réponses envoyées en
privé, à moins que ce ne soit justifié et mentionné dans le mail. Sans
compter que depuis hier on a des pannes de courant en salle des
serveurs.
Sylvain , dans le message <5c85138d$0$20330$, a écrit :
Comme a priori mon premier message n'est pas passé, je reposte.
Ce n'est pas qu'il n'est pas passé, c'est que tu l'as envoyé en privé, et j'ai pour politique de ne pas répondre aux réponses envoyées en privé, à moins que ce ne soit justifié et mentionné dans le mail. Sans compter que depuis hier on a des pannes de courant en salle des serveurs.
Sylvain
Le 10/03/2019 à 17:00, Nicolas George a écrit :
Sylvain , dans le message <5c85138d$0$20330$, a écrit :
Comme a priori mon premier message n'est pas passé, je reposte.
Ce n'est pas qu'il n'est pas passé, c'est que tu l'as envoyé en privé, et j'ai pour politique de ne pas répondre aux réponses envoyées en privé, à moins que ce ne soit justifié et mentionné dans le mail. Sans compter que depuis hier on a des pannes de courant en salle des serveurs.
Je me doutais d'un truc comme ça :) Ce n'est pourtant pas la première fois que je fais cette gaffe...
Le 10/03/2019 à 17:00, Nicolas George a écrit :
Sylvain , dans le message <5c85138d$0$20330$426a74cc@news.free.fr>, a
écrit :
Comme a priori mon premier message n'est pas passé, je reposte.
Ce n'est pas qu'il n'est pas passé, c'est que tu l'as envoyé en privé,
et j'ai pour politique de ne pas répondre aux réponses envoyées en
privé, à moins que ce ne soit justifié et mentionné dans le mail. Sans
compter que depuis hier on a des pannes de courant en salle des
serveurs.
Je me doutais d'un truc comme ça :)
Ce n'est pourtant pas la première fois que je fais cette gaffe...
Sylvain , dans le message <5c85138d$0$20330$, a écrit :
Comme a priori mon premier message n'est pas passé, je reposte.
Ce n'est pas qu'il n'est pas passé, c'est que tu l'as envoyé en privé, et j'ai pour politique de ne pas répondre aux réponses envoyées en privé, à moins que ce ne soit justifié et mentionné dans le mail. Sans compter que depuis hier on a des pannes de courant en salle des serveurs.
Je me doutais d'un truc comme ça :) Ce n'est pourtant pas la première fois que je fais cette gaffe...
zeLittle
"Nicolas George" a écrit dans le message de groupe de discussion : 5c8531f9$0$31419$
Et accessoirement, ça n'AJOUTE pas d'entropie, ça se contente de la diluer.
Oui, à ordinateur constant dans le temps. Mais non, en tenant compte de l'évolution des fréquences et des cœurs des CPU qui augmentent de paire: ce sont justement là, des moyens de garder l'entropie (c'est à dire l'imprédictibilité des nombres générés sur l'espace de distribution des nombres considéré) identiquement "concentrée", identiquement distribuée, à durée plancher de génération également fixée. Bref, ce sont des moyens différents, ou supplétifs, pour garder l'entropie identiquement "concentrée", par cycle de CPU si on change les PC tous les 5 ans ;-) .
"Nicolas George" a écrit dans le message de groupe de discussion :
5c8531f9$0$31419$426a74cc@news.free.fr...
Et accessoirement, ça n'AJOUTE pas d'entropie, ça se contente de la
diluer.
Oui, à ordinateur constant dans le temps.
Mais non, en tenant compte de l'évolution des fréquences et des cœurs des
CPU qui augmentent de paire: ce sont justement là, des moyens de garder
l'entropie (c'est à dire l'imprédictibilité des nombres générés sur l'espace
de distribution des nombres considéré) identiquement "concentrée",
identiquement distribuée, à durée plancher de génération également fixée.
Bref, ce sont des moyens différents, ou supplétifs, pour garder l'entropie
identiquement "concentrée", par cycle de CPU si on change les PC tous les 5
ans ;-) .
"Nicolas George" a écrit dans le message de groupe de discussion : 5c8531f9$0$31419$
Et accessoirement, ça n'AJOUTE pas d'entropie, ça se contente de la diluer.
Oui, à ordinateur constant dans le temps. Mais non, en tenant compte de l'évolution des fréquences et des cœurs des CPU qui augmentent de paire: ce sont justement là, des moyens de garder l'entropie (c'est à dire l'imprédictibilité des nombres générés sur l'espace de distribution des nombres considéré) identiquement "concentrée", identiquement distribuée, à durée plancher de génération également fixée. Bref, ce sont des moyens différents, ou supplétifs, pour garder l'entropie identiquement "concentrée", par cycle de CPU si on change les PC tous les 5 ans ;-) .
Nicolas George
"zeLittle" , dans le message <5c855f78$0$15502$, a écrit :
Oui, à ordinateur constant dans le temps. Mais non, en tenant compte de l'évolution des fréquences et des cœurs des CPU qui augmentent de paire: ce sont justement là, des moyens de garder l'entropie (c'est à dire l'imprédictibilité des nombres générés sur l'espace de distribution des nombres considéré) identiquement "concentrée", identiquement distribuée, à durée plancher de génération également fixée. Bref, ce sont des moyens différents, ou supplétifs, pour garder l'entropie identiquement "concentrée", par cycle de CPU si on change les PC tous les 5 ans ;-) .
Je n'ai rien compris.
"zeLittle" , dans le message <5c855f78$0$15502$426a74cc@news.free.fr>, a
écrit :
Oui, à ordinateur constant dans le temps.
Mais non, en tenant compte de l'évolution des fréquences et des cœurs des
CPU qui augmentent de paire: ce sont justement là, des moyens de garder
l'entropie (c'est à dire l'imprédictibilité des nombres générés sur l'espace
de distribution des nombres considéré) identiquement "concentrée",
identiquement distribuée, à durée plancher de génération également fixée.
Bref, ce sont des moyens différents, ou supplétifs, pour garder l'entropie
identiquement "concentrée", par cycle de CPU si on change les PC tous les 5
ans ;-) .
"zeLittle" , dans le message <5c855f78$0$15502$, a écrit :
Oui, à ordinateur constant dans le temps. Mais non, en tenant compte de l'évolution des fréquences et des cœurs des CPU qui augmentent de paire: ce sont justement là, des moyens de garder l'entropie (c'est à dire l'imprédictibilité des nombres générés sur l'espace de distribution des nombres considéré) identiquement "concentrée", identiquement distribuée, à durée plancher de génération également fixée. Bref, ce sont des moyens différents, ou supplétifs, pour garder l'entropie identiquement "concentrée", par cycle de CPU si on change les PC tous les 5 ans ;-) .
