Introduction
En cryptographie, l'on dispose d'un système fiable d'un point de vue mathématique pour crypter un texte. Le principe de base de ce système consiste à prendre un texte, de le transformer en une suite de chiffres (0/1), de prendre une suite de chiffres complètement aléatoire, puis de faire l'addition du texte et de la suite aléatoires, pour décrypter il suffit de faire l'opération inverse. D'un point de vue mathématique, la difficulté consiste à avoir une suite complètement aléatoire de la meme taille que le message. D'un point de vue pratique, il faut que la suite aléatoire puisse être à disposition des deux côtés. Inutile de préciser que le masque ne doit être utilisé qu'une seule fois à cause des zéros qui sont dans le texte à coder. Le hasard est en lui même un véritable défi d'un point de vue des mathématiques. Il n'y a, je pense, pas vraiment de définition du hasard, il y a plutôt des tests ou dit différemment l'on sait ce qui n'est pas du hasard "point de vue perso" l'on a tout de même un exemple PI. Il existe plusieurs générateurs, mais pour qu'ils puissent fonctionner, il faut qu'ils aient à leur disposition une bonne source d'entropie. Dit différemment cela veut dire que la suite générée n'est pas reproductible puisque il faut que le codeur et le décodeur est à leur disposition la même source d'entropie et dans ce cas le problème de la transmission se repose.
Il existe aussi un autre générateur qui lui remplit toutes les conditions : le BBS créé par Lenore Blum, Manuel Blum et Michael Shub. Blum_Blum_Shub p q premier xn=(xn-1)^2%(p*q) et l'on prend le bit de point le plus faible à chaque tirage réputé lent, ils n'ont pas encore vu le mien :-) et démontré sûr si p*q n'est pas factorisable dixit wikipedia. Bon, dans tous les cas, je lui trouve un petit défaut il est cyclique, ou dit différemment, l'on ne peut pas faire plus de p*q tirage. je peux dire aussi pour faire sérieux que la bande passante est limitée par p*q.

Le principe de mon générateur

je prend deux nombres premiers au hasard ça commence mal mais non c'est la graine je fais croître le premier nombre premier jusqu'à une taille définie, elle aussi dans la graine par exemple une bonne centaine de bits pour avoir à disposition un certain choix, voir fonction de densité des nombres premiers. Je réitère l'opération avec le 2ieme nombre premier, avec une taille 2 fois plus petite que le premier. Puis je calcule le reste du premier nombre divisé par le deuxieme en gros p0 modulo p1. Donc d'un point de vue mathématique, l'on a une infinité de points d'entrée, les nombres premiers, donc une infinité de combinaisons possibles, et donc une bonne bande passante. L'on peut aussi, si l'on veut varier les cuisines nombre premier modulo la différence Ou tout autre cuisine à assaisonner selon le goût. Attention tout de meme ne pas utiliser les nombres premiers tels quels. Le générateur produit des nombres premiers avec une signature assez similaire en base 2. Cette idée est une application de mon générateur de nombre premier de type Dirichlet. Je ne garantis rien, mais si vous trouvez une attaque mathématique, je suis preneur. Il est bien évident que cela n'est pas utilisable pour de grande quantité de texte, puissance de calcul actuelle trop faible. Mais peut trés bien être utilisé pour coder des clés de session ou faire des authentifications. Générer 1 ko d'aléas ne coûte pas trés cher et garantit à mon avis une excellente confidentialité via un opt. Avis perso, mais suis-je encore impartial ....

ceci étant dit j'attire l'attention des éventuels utilisateurs

suite à un appel à contribution du sstic 2007 auquel j'ai répondu pour une présentation de 30 minutes avec le pdf ici le comité de lecture n'a pas retenu ma contribution


Bonjour,
Je suis au regret de vous annoncer que votre soumission n'a pas été
retenue par le comité de programme.
Vous pourrez trouver, en fin d'aprés-midi, sur le site web, les revues
des relecteurs, revues qui, je l'espère, s'avèreront constructives.
Il vous sera tout de même possible de présenter vos travaux lors de
sessions informelles (rump sessions) d'une dizaine de minutes
environ. Il suffit pour cela d'en faire la demande par mail à
l'adresse ....@sstic.org.
Je vous remercie, au nom du comité de programme, de l'intérêt que vous
avez porté au SSTIC en nous soumettant vos travaux, et j'espère vous
croiser lors de la conférence.

Cordialement.


dit différemment bien ....
ou s'est pas un trés bon signe surtout si l'on regarde les CV du comité de lecture cela inspire le respect.
Bref, dans tous les cas, je les remercie.















Free counter and web stats