Générateur parfait de nombres aléatoires ???

Le
emile
J'ai proposé au forum fr.sci.maths une discussion relative à la
génération de nombres aléatoires par chiffrement. Mon but n'est pas de
réaliser un générateur de nombres aléatoires mais plutôt de const=
ater
que si la séquence des nombres générés est strictement aléatoire,
l'algorithme utilisé peut être considéré comme non cassable. Peut-on
dire que si les blocs chiffrés sont aléatoires vis-à-vis des blocs =
à
chiffrer, il est illusoire de pouvoir casser la clef par une
cryptanalyse différentielle ou linéaire? c'est précisément à ce n=
iveau
que les opinions m'intéressent.

http://groups.google.com/group/fr.sci.maths/browse_thread/thread/dff2bea39a=
6c6f7c/fbba159f19c35019#fbba159f19c35019

Le cryptosystème expérimental classicsys est de nouveau opérationnel.
Le serveur avait rendu l'âme après 13 ans de bons et loyaux services.
Le but que je poursuis est de montrer la faisabilité d'un tel projet.
Voir:
www.ulb.ac.be/di/scsi/classicsys/experim.htm

Emile
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Philippe Lheureux
Le #586118
Je préfère le système que j'avais immaginé pour mon logiciel CDP
www.superlutin.net/crypto.html
le hasard était généré par 3 facteurs différents

1 - l'initialisation du générateur de hasard ( bien conventionnel puisqu'il
s'agissait de celui du visual basic = pour chaque lettre tapée au clavier .
( choix du systeme )
2 - une autre initialisation puis un choix au hasard pour le choix du codage
a l'intérieur du systeme employé.
3- le tout dépendant de l'heure du message , de la vitesse de l'horloge de
l'ordinateur , de la lettre chiffrée et de la vitesse de frappe au clavier
de celui qui rédige le message.

Le hasard était ainsi obtenu sans risque pour chaque lettre chiffrée , le
seul probleme est que c'etait lent et que cela ne permettait pas de crypter
des images.

Je pense que toute formule mathématique a ses points faibles , le hasard
nait plutot du chaos.
Jean-Marc Desperrier
Le #586117
wrote:
[...] si la séquence des nombres générés est strictement aléatoire,
l'algorithme utilisé peut être considéré comme non cassable. Peut-on
dire que si les blocs chiffrés sont aléatoires vis-à-vis des blocs à
chiffrer, il est illusoire de pouvoir casser la clef par une
cryptanalyse différentielle ou linéaire? c'est précisément à ce niveau
que les opinions m'intéressent. [...]


Non, ce n'est pas le cas.

Par exemple la sortie du DES paraît de l'extérieur suffisament aléatoire
pour qu'il ait été retenu sans hésitation dans le standard X9.17 pour
générer des nombres aléatoires alors même qu'en fait il s'est révélé par
la suite être sensible à ces deux attaques.

On considère cependant dans l'autre sens que l'aspect apparement
totalement aléatoire du résultat chiffré est une condition minimale
indispensable pour qu'il soit sûr (pour tous les algorithmes où la
taille du chiffré est la même que la taille des données en entrée).

PS : je pense que tu peux te contenter d'ignorer le message de Lheureux

Oncle Dom
Le #586116
Philippe Lheureux dans son message
46a5b290$0$27367$,
nous a fait l'honneur d'écrire:
Je préfère le système que j'avais immaginé pour mon logiciel CDP
Le revoila!

A vos tartes. Prèts?
http://perso.orange.fr/oncle.dom/humour/entartometre/lheureux.htm

--
Oncle Dom
_________
http://perso.orange.fr/oncle.dom/

Emile
Le #586115
On 24 juil, 10:54, Jean-Marc Desperrier

PS : je pense que tu peux te contenter d'ignorer le message de Lheureux


Evidemment, cela va de soi.

J'ai pondu un petit texte, qu'en penses tu?
Voir http://cjoint.com/?hzkOZJChns

YBM
Le #586114
On 24 juil, 10:54, Jean-Marc Desperrier
PS : je pense que tu peux te contenter d'ignorer le message de Lheureux


Evidemment, cela va de soi.

J'ai pondu un petit texte, qu'en penses tu?
Voir http://cjoint.com/?hzkOZJChns


une chose qu'on peut penser est qu'on ne met pas des fichiers au
format rtf en ligne quand on est poli.


Emile
Le #585614
On 26 juil, 05:07, YBM
une chose qu'on peut penser est qu'on ne met pas des fichiers au
format rtf en ligne quand on est poli.


Donc je suis impoli en mettant en ligne un fichier au format
rtf !!!, selon quels critères?. Je laisse à l'appréciation des autres
correspondants votre argumentation à ce sujet.

Au lieu de reproches sur la forme, j'aurais préféré des critiques
sur le fond. Est-ce dérangeant de proposer une classification des
algorithmes de chiffrement en terme de générations à l'instar des
microprocesseurs, classification basée sur la grandeur des boîtes de
substitution?

Le DES avec ses boîtes de 4 bits, l'AES avec 32 bits formeraient
les générations 1 et 2 tandis que le SED avec une boîte 127 bits
opérant en un seul tour serait classé dans la génération 3.

La justification du passage d'une génération à la suivante
s'inscrit normalement dans un apport d'améliorations. L'avantage
majeur du SED est sa transparence. De plus, il est possible de
réaliser des réductions homothétiques de l'algorithme avec des blocs
de 7 ou 17 bits, ce qui permet d'effectuer une exploration exhaustive
montrant que les blocs chiffrés sont strictement aléatoires par
rapport aux blocs à chiffrer car ils obéissent à une distribution des
probabilités suivant la loi de Poisson. Les cryptanalyses linéaires et
différentielles ne seraient pas applicables.

Emile

Manuel Sabban
Le #585613
Vendredi vers 16 heures Emile disait




Donc je suis impoli en mettant en ligne un fichier au format
rtf !!!, selon quels critères?. Je laisse à l'appréciation des autres
correspondants votre argumentation à ce sujet.


Je suis d'accord avec lui.

montrant que les blocs chiffrés sont strictement aléatoires par
rapport aux blocs à chiffrer car ils obéissent à une distribution des


Je ne suis pas expert en cryptographie, mais il me semble qu'il y a un
problème avec cette phrase, en effet Shannon écrit avec raison que
l'entropie à la sortie d'un système est au plus égale à celle à son
entrée (A mathematical theory of communication, p15, théorème
7, http://plan9.bell-labs.com/cm/ms/what/shannonday/shannon1948.pdf).
Ou alors je n'ai rien compris à la signification du <<strictement>>.
--
Manuel Sabban




Thierry B.
Le #585612
--{ Emile a plopé ceci: }--

une chose qu'on peut penser est qu'on ne met pas des fichiers au
format rtf en ligne quand on est poli.


Donc je suis impoli en mettant en ligne un fichier au format
rtf !!!, selon quels critères?. Je laisse à l'appréciation des autres
correspondants votre argumentation à ce sujet.


Selon le critère que tu demandes aux gens de se décarcasser pour
tenter de lire un format non (ou très mal) documenté, et que les
gens n'ont pas envie de se prendre la tête avec ça. Pourquoi ne
pas avoir utilisé le HTML, par exemple ?

Suivi ailleurs.

--
David Lightman: What is the primary goal?
Joshua: You should know, Professor. You programmed me.
David Lightman: C'mon. What is the primary goal?
Joshua: To win the game.


Emile
Le #585609
On 27 juil, 16:32, Manuel Sabban
Je ne suis pas expert en cryptographie, mais il me semble qu'il y a un
problème avec cette phrase, en effet Shannon écrit avec raison que
l'entropie à la sortie d'un système est au plus égale à celle à son
entrée (A mathematical theory of communication, p15, théorème
7,http://plan9.bell-labs.com/cm/ms/what/shannonday/shannon1948.pdf).
Ou alors je n'ai rien compris à la signification du <<strictement>>.
--
Manuel Sabban


Vous tiquez sur le fait d'utiliser le terme "strictement". Je n'ai
pas de réponse à vous donner dans le sens qu'il faudrait intégrer ce
terme dans la théorie de Shannon concernant l'entropie à la sortie
d'un système. Je peux par contre vous donner tous les éléments qui
prouvent que les nombres générés sont bien aléatoires, et, qu'en
utilisant les moyens les plus sophistiqués, il ne sera pas possible de
mettre le caractère aléatoire en défaut.

Soit N = 2^127-1. Vous avez choisi une clef quelconque de 1 à N et
vous introduisez (par la pensée) les nombres à chiffrer de 1 à N. Les
N résultats des chiffrements sont aléatoires par rapport aux nombres
de 1 à N. Si vous ne connaissez pas la clef, vous ne pouvez pas
préduire les nombres qui se vont se produire, mais si vous recommencez
les chiffrements, vous trouverez la même séquence des nombres.

Si vous faites une réduction homothétique de l'algorithme SED de
127 bits à 17 bits, vous pouvez effectuer une exploration exhaustive
des résultats de chiffrement pour les entrées de 1 à N$ (N$ = 2^17- 1 =
131.071) Pour chaque chiffrement, il y a d'abord le calcul du vecteur
intermédiaire dont le logarithme discret dans le corps fini défini
suivant le trinôme P^0+P^5+P^17 est égal au produit modulo-N$ du
logarithme discret du vecteur d'entrée par la clef. Le vecteur
intermédiaire, un nombre compris de 1 à N$ a également un logarithme
discret dans le corps fini défini suivant le trinôme P^0+P^6+P^17.
C'est le changement du logarithme discret qui réalise en quelque sorte
la boîte de substitution opérée sur 17 bits. Le résultat du
chiffrement est finalement obtenu par le calcul du vecteur dont le
logarithme discret dans le corps fini de P^0+P^6+P^17 est égal au
produit du logarithme du vecteur intermédiaire par la clef. Le rôle de
la boîte de substitution revient en quelque sorte à la mise en place
d'un facteur X qui a pour effet de convertir le logarithme discret du
vecteur intermédiaire du corps fini P^0+P^5+P^17 au corps fini
P^0+P^6+P^17. Il existe donc N$ boîtes de substitution qui
correspondent à ces N$ facteurs X. Certains facteurs X sont
inexistants, d'autres y figurent en deux ou même "i" valeurs. Les
valeurs de ces N$ facteurs X se présentent suivant une distribution
homogène de 1 à N$. La vérification de cette homogéniété peut s e faire
par la recherche de la distribution des probabilités de ces valeurs
qui doivent répondre à une loi de distribution de Poisson. La loi de
Poisson est donnée par la relation P(i) = (lambda)^i / i ! *
e^(lambda) où lambda est la moyenne. Comme il y a 2^n-1 tirages pour
2^n-1 possibilités de résultat, la moyenne vaut "1". Nous obtenons le
tableau suivant.

Valeurs théoriques Valeurs
(2^17-1)*P(i) expérimentales
(1) .
et sigma pour le facteur X

i = 0 48.218,34 219,59 48.443 (+1,02 sig)
i = 1 48.218,34 219,59 48.054 (- 0,75 sig)
i = 2 24.191,71 155,27 23.927 (- 1,70 sig)
i = 3 8.036,39 89,64 8.044 (+ 0,08 sig)
i = 4 2.009,09 44,82 2.068 (+ 1,31 sig)
i = 5 401,81 20,04 448 (+ 2,30 sig)
i = 6 66,96 8,18 67 (+ 0,00 sig)
i = 7 9,56 3,09 10 (+ 0,14 sig)
i = 8 1,19 1,09 0 (- 1,09 sig)
i = 9 0,13
1
i = 10 0,01 0
i = 11 0,00 1
i = 12...15 0,00 0
i = 16 0,00
1

Pensez vous que l'on peut être satisfait de cette distribution
expérimentale de probabilité? Pour ma part, je pense que oui. Si l'on
repasse à l'algorithme SED avec des blocs de 127 bits, les conclusions
restent les mêmes, mais il n'y aura plus de possibilité de
vérification, les nombres sont trop grands et il faut seulement
accepter la vérification homothétique. A mon humble avis, je ne pense
pas que le terme utilisé "strictement" n'est pas exagéré.

Emile.

PS: pour vous faciliter le téléchargement, j'ai mis le fichier 3ième
Génération au format pdf. Voir éventuellement

http://cjoint.com/?hCimEiuj3M

Alain
Le #586779
j'arrive pas a lire le document (j'ai firefox... c'est peut être ca)...
le RTF je devrais arriver a le lire...

mais bon.

pour faire du vrai hasard parfais, problème bien connu en militaire, il
n'y a que des processus physiques vraiment aléatoire suivis de processus
de mélange de bonne qualité

pour du hasard pratique (pseudo-aléatoire, mais imprévisible par un
calcul), il y a une méthode cryptographiquement solide si on a confiance
en un algorithme de chiffrement donné .
c'est même un standard (X quelque chose)

l'idée c'est d'utiliser un algo de chiffrement qui reprend le résultat
précédent avec une clé réellement secrete, et produit un bloc de bit. et
ainsi de suite...

si l'algo de chiffrement est bon, il est garanti que l'on ne peut
obtenir aucune information sur un bit suivant d'après un bit précédent
sans avoir la clé, et réciproquement...
il faut par contre une vrai clé aléatoire... et pas pseudo-aléatoire.
et évidemment un algo solide.


le problème est tellement connu et fondamental que si quelque chose de
nouveau apparaissait on le verrais dans les journaux sérieux.

les propriétés statistiques sont loin d'être suffisante pour la crypto,
et même souvent pour la physique.



Vendredi vers 16 heures Emile disait
Donc je suis impoli en mettant en ligne un fichier au format



rtf !!!, selon quels critères?. Je laisse à l'appréciation des autres
correspondants votre argumentation à ce sujet.


Je suis d'accord avec lui.

montrant que les blocs chiffrés sont strictement aléatoires par
rapport aux blocs à chiffrer car ils obéissent à une distribution des


Je ne suis pas expert en cryptographie, mais il me semble qu'il y a un
problème avec cette phrase, en effet Shannon écrit avec raison que
l'entropie à la sortie d'un système est au plus égale à celle à son
entrée (A mathematical theory of communication, p15, théorème
7, http://plan9.bell-labs.com/cm/ms/what/shannonday/shannon1948.pdf).
Ou alors je n'ai rien compris à la signification du <<strictement>>.






Publicité
Poster une réponse
Anonyme