Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Entropie d'un syst=c3=a8me et /dev/random

56 réponses
Avatar
Sylvain
Bonjour,

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.

Merci,
Sylvain

10 réponses

2 3 4 5 6
Avatar
Nicolas George
Sylvain , dans le message <5c890271$0$20328$, a
écrit :
En effet, pour ces tests, il ne semble pas y avoir de grosses
différences entre /dev/random et /dev/urandom...

Principe général en sécurité et en cryptographie :
Si tu veux de la sécurité, tu utilises, que ce soit pour chiffrer, pour
signer, pour générer des nombres aléatoires ou pour tester tout ça, des
algorithmes qui ont été étudiés par de nombreux spécialistes reconnus,
pas des algorithmes qui ont été développés par un soi-disant génie tout
seul dans son garage.
Avatar
remy
import java.util.*;
import java.lang.*;
import java.math.*;
public class gene
{
public static void main(String args[])
{
Random rnd = new Random();
while(true)
{
BigInteger p1 = BigInteger.probablePrime(1024, rnd);
BigInteger p2 = BigInteger.probablePrime(512, rnd);
String p=(p1.mod(p2)).toString(2);
System.out.println(p.substring(p.length()-9,p.length()-1));
}
}
}
:~/Bureau/Gene$ javac *.java
:~/Bureau/Gene$ java gene
01001011
10000111
11011111
00101010
01011110
01100100
11111110
:~/Bureau/Gene$ java gene
10010110
01000110
01101111
01010000
01001100
10101010
01011001
:~/Bureau/Gene$ java gene
01111001
10000100
01001110
10100111
11011100
10101100
10000100
il ne reste juste a crée un entier binaire et l’écrire dans un fichier
cdl remy
ps je suis pas opposer au don :-)
Avatar
Sylvain
Le 14/03/2019 à 09:43, remy a écrit :
Le 13/03/2019 à 17:43, Sylvain a écrit :
bon ok je reprend mon code n’utilise pas la formule bbs
les résultas que j'ai poste sont issu de mon générateur de nombre pseudo
aléatoire mon algo et decrit ici
http://remyaumeunier.chez-alice.fr/pdf/conference.pdf
en gros tu prend 2 nombre premier puis tu calcule  px modulo py=et tu
récupère quelque bit de poid faible et tu change l'un ou les 2 nombres
premiers
cdl remy
il utilise mon generateur de grand nombre premier

... et comment ton générateur de grands nombres premiers garantit-il que
les nombres premiers obtenus sont toujours différents ? Tu les
sélectionnes de façon aléatoire ? :-)
Avatar
Sylvain
Le 14/03/2019 à 10:26, Nicolas George a écrit :
Sylvain , dans le message <5c890271$0$20328$, a
écrit :
En effet, pour ces tests, il ne semble pas y avoir de grosses
différences entre /dev/random et /dev/urandom...

Principe général en sécurité et en cryptographie :
Si tu veux de la sécurité, tu utilises, que ce soit pour chiffrer, pour
signer, pour générer des nombres aléatoires ou pour tester tout ça, des
algorithmes qui ont été étudiés par de nombreux spécialistes reconnus,
pas des algorithmes qui ont été développés par un soi-disant génie tout
seul dans son garage.

Pour ma part, je vais en rester sur la base de urandom.
J'ai remarqué que les mots de passe que je génère à la main font
inconsciemment presque toujours appel à des séquences répétitives :
sigles (ex. : Qt, HP, etc.), nombres (ex. : 65 répété souvent), etc.
urandom fera donc mieux que moi... de toute façon... et sera suffisant
pour le niveau de sécurité que mon ordi exige : je ne travaille pas sur
des données privées protégées voire classifiées...
Merci pour vos lumières !
Sylvain
Avatar
Nicolas George
remy , dans le message <5c8b67e8$0$21610$, a
écrit :
en gros c'est pas la qualité intrinsèque du bouzin qui compte
c'est la quantité de fric que le bouzin rapport qui fait que des mec
toi vont après dire

N'importe quoi. La qualité intrinsèque d'une chose n'est pas une notion
bien définie. Mais ce qui compte, ça n'a rien à voir avec le fric, ça à
tout à voir avec la compétence reconnue de tous ceux qui l'ont examiné.
Par exemple, tu perds un temps considérable à faire des tests
statistiques sur ton PRNG, mais tu n'en as absolument pas fait une
cryptanalyse. Et je devine que tu ne saurais même pas comment t'y
prendre.
Avatar
remy
Le 15/03/2019 à 16:49, Nicolas George a écrit :
Par exemple, tu perds un temps considérable à faire des tests
statistiques sur ton PRNG, mais tu n'en as absolument pas fait une
cryptanalyse. Et je devine que tu ne saurais même pas comment t'y
prendre.

tu devine mal
j'ai proposer cette solution pour être compréhensible
mais l'orignal lui utilise mon generateur de nombre premier
qui lui minimise les tests
http://remyaumeunier.chez-alice.fr/premier.php
11001010101111110010111
110111001010101111110010111
101110111001010101111110010111
10101110111001010101111110010111
10101010101110111001010101111110010111
cela revient a rajoute quelque bits en generale ou en moyenne
moins de 8 bits et donc a faire 256 test et cela quelque soit la taille
et oui perdu
mais c'est pas grave j'ai prie l’habitude ,cela m’amuse t oujours un peut
cdl remy
--
http://remyaumeunier.chez-alice.fr/
toujours autant dyslexique
Avatar
Nicolas George
remy , dans le message <5c8f65dd$0$15177$, a
écrit :
tu devine mal

<snip>
... et tu confirmes que tu ne connais rien à la cryptographie.
Avatar
remy
Le 18/03/2019 à 14:01, Nicolas George a écrit :
remy , dans le message <5c8f65dd$0$15177$, a
écrit :
tu devine mal

<snip>
... et tu confirmes que tu ne connais rien à la cryptographie.

yu as poser comme question
tu perds un temps considérable à faire des tests
statistiques

je te répond et démontre que non parce que j'utilise des nombr e premier
un peu spéciaux
11001010101111110010111
110111001010101111110010111
101110111001010101111110010111
10101110111001010101111110010111
10101010101110111001010101111110010111
pour passer de
11001010101111110010111
a
110111001010101111110010111
j'ai rajoute 1101 devant donc j'ai fait 13 test
aller un autre exemple parce que c'est pas tres claire
pour passer de
5572175323206987633405256618503372230529680507092843602602577667023729149 228581821876849000655392300590013309174098744928252805780140145860503
a
2950502936656457471534404205817916117692586131497680862870127600126114646 824905914865056239195316763531442372160032299640438745487608737417224087
j'ai rajoute 10100101 devant ce qui correspond a faire 165 test pour
passe de l'un a l’autre
de tout manier tu restera avec tes certitude et franchement c'est pas
tres grave
cdl remy
--
http://remyaumeunier.chez-alice.fr/
toujours autant dyslexique
Avatar
ptilou
Le vendredi 8 mars 2019 12:10:31 UTC-5, Sylvain a écrit :
Bonjour,
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 p as 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 bloqu e le
logiciel. Il suffit alors de bouger la souris pour faire avancer la
génération.

On me confirme que urandom utilise le code random !
J'aimerais connaître les autres sources d'entropie afin d'évite r que mon
logiciel bloque de temps à autre en attendant que cette entropie soi t
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ér ateur sans avoir à
bouger la souris.
Merci,
Sylvain
Avatar
remy
pour le débat du vendredi
j'ai introduit mon generateur de nombre premier dans le bouzin
parce que le random du java au bout de 400 k il me sort les même nom bre
premier et j'ai compté le nombre de teste pour crée des nombres premier
que j'affiche donc
import java.util.*;
import java.lang.*;
import java.math.*;
import java.io.*;
public class gene
{
static FileOutputStream file;
public static void main(String args[])
{
BigInteger p1,p2,tmpp1,tmpp2;
String p;
//initialisation if args[] is empy
Random rnd = new Random();
p1 = BigInteger.probablePrime(512, rnd);
p2 = BigInteger.probablePrime(128, rnd);
tmpp1=p1;
tmpp2=p2;
try {file=new FileOutputStream ("sortie08.bin");
} catch (FileNotFoundException e){System.out.println(e);}
while(true)
{
p=(p1.mod(p2)).toString(2);
write(p.substring(0,p.length()-3));
p1=newP(p1,p1.toString(2).length());
p2=newP(p2,p2.toString(2).length());
if(p1.toString(2).length()>1024){p1 =
newP(tmpp1,tmpp1.toString(2).length()/2);tmpp1=p1;}
if(p2.toString(2).length()>256) {p2 =
newP(tmpp2,tmpp2.toString(2).length()/2);tmpp2=p2;}
}
}
public static void write(String p)
{
byte monByte;
String t;
int max=(int)p.length()/8-2;
for(int i=0;i<max;i++)
{
t=p.substring(p.length()-(i+1)*8,p.length()-i*8);
monByte = (byte)Integer.parseInt(t,2);
System.out.println(t+" "+monByte);
try {file.write(monByte);
} catch (IOException e){System.out.println(e);}
}
}
public static BigInteger newP(BigInteger p,int n )
{
BigInteger pow=new BigInteger("2");
pow=pow.pow(n);
p=p.add(pow);
int qtTest=0;
while(!p.isProbablePrime(100)){ p=p.add(pow);qtTest++;}
System.out.println("qt de test pour generer un nombre premier
"+qtTest+" taille en base 2 "+p.toString(2).length());
return p;
}
}
10100011 -93
10010100 -108
00100001 33
11110001 -15
00100101 37
10011100 -100
00101011 43
10011101 -99
10110111 -73
11110100 -12
qt de test pour generer un nombre premier 190 taille en base 2 819
qt de test pour generer un nombre premier 14 taille en base 2 237
01101101 109
01101000 104
01001001 73
00111101 61
10000100 -124
11011000 -40
00011101 2
l'analyse de la sortie sortie08 sur 100k
Value Char Occurrences Fraction
0 408 0.004002
1 383 0.003757
2 374 0.003668
3 400 0.003923
4 395 0.003874
....
253 ý 375 0.003678
254 þ 375 0.003678
255 ÿ 426 0.004178
Total: 101952 1.000000
Entropy = 7.998391 bits per byte.
Optimum compression would reduce the size
of this 101952 byte file by 0 percent.
Chi square distribution for 101952 samples is 227.16, and randomly
would exceed this value 89.45 percent of the times.
Arithmetic mean value of data bytes is 127.6542 (127.5 = random).
Monte Carlo value for Pi is 3.133239171 (error 0.27 percent).
Serial correlation coefficient is 0.001973 (totally uncorrelated = 0.0) .
Value Char Occurrences Fraction
0 408 0.004002
1 383 0.003757
2 374 0.003668
3 400 0.003923
4 395 0.003874
....
251 û 827 0.008112
252 ü 821 0.008053
253 ý 780 0.007651
254 þ 745 0.007307
255 ÿ 426 0.004178
Total: 101952 1.000000
Entropy = 7.562018 bits per byte.
Optimum compression would reduce the size
of this 101952 byte file by 5 percent.
Chi square distribution for 101952 samples is 44672.94, and randomly
would exceed this value less than 0.01 percent of the times.
Arithmetic mean value of data bytes is 134.6008 (127.5 = random).
Monte Carlo value for Pi is 2.808615819 (error 10.60 percent).
Serial correlation coefficient is 0.000485 (totally uncorrelated = 0.0) .
Entropy = 1.000000 bits per bit.
Optimum compression would reduce the size
of this 815616 bit file by 0 percent.
Chi square distribution for 815616 samples is 0.02, and randomly
would exceed this value 88.55 percent of the times.
Arithmetic mean value of data bits is 0.4999 (0.5 = random).
Monte Carlo value for Pi is 3.133239171 (error 0.27 percent).
Serial correlation coefficient is -0.000054 (totally uncorrelated = 0.0 ).
Value Char Occurrences Fraction
0 407873 0.500080
1 407743 0.499920
Total: 815616 1.000000
Entropy = 1.000000 bits per bit.
Optimum compression would reduce the size
of this 815616 bit file by 0 percent.
Chi square distribution for 815616 samples is 0.02, and randomly
would exceed this value 88.55 percent of the times.
Arithmetic mean value of data bits is 0.4999 (0.5 = random).
Monte Carlo value for Pi is 3.133239171 (error 0.27 percent).
Serial correlation coefficient is -0.000054 (totally uncorrelated = 0.0 ).
0,File-bytes,Entropy,Chi-square,Mean,Monte-Carlo-Pi,Serial-Correlation
1,101952,7.998391,227.163842,127.654151,3.133239,0.001973
0,File-bytes,Entropy,Chi-square,Mean,Monte-Carlo-Pi,Serial-Correlation
1,101952,7.998391,227.163842,127.654151,3.133239,0.001973
2,Value,Occurrences,Fraction
3,0,408,0.004002
3,1,383,0.003757
3,2,374,0.003668
3,3,400,0.003923
3,4,395,0.003874
3,5,397,0.003894
.003688
3,249,387,0.003796
3,250,402,0.003943
3,251,414,0.004061
3,252,416,0.004080
3,253,375,0.003678
3,254,375,0.003678
3,255,426,0.004178
0,File-bytes,Entropy,Chi-square,Mean,Monte-Carlo-Pi,Serial-Correlation
1,101952,7.562018,44672.939109,134.600793,2.808616,0.000485
0,File-bits,Entropy,Chi-square,Mean,Monte-Carlo-Pi,Serial-Correlation
1,815616,1.000000,0.020721,0.499920,3.133239,-0.000054
0,File-bits,Entropy,Chi-square,Mean,Monte-Carlo-Pi,Serial-Correlation
1,815616,1.000000,0.020721,0.499920,3.133239,-0.000054
2,Value,Occurrences,Fraction
3,0,407873,0.500080
3,1,407743,0.499920
0,File-bits,Entropy,Chi-square,Mean,Monte-Carlo-Pi,Serial-Correlation
1,815616,0.997887,2388.145838,0.527056,2.808616,0.045483
2,Value,Occurrences,Fraction
3,0,385741,0.472944
3,1,429875,0.527056
--
http://remyaumeunier.chez-alice.fr/
toujours autant dyslexique
2 3 4 5 6