J'ai propos=E9 au forum fr.sci.maths une discussion relative =E0 la
g=E9n=E9ration de nombres al=E9atoires par chiffrement. Mon but n'est pas de
r=E9aliser un g=E9n=E9rateur de nombres al=E9atoires mais plut=F4t de const=
ater
que si la s=E9quence des nombres g=E9n=E9r=E9s est strictement al=E9atoire,
l'algorithme utilis=E9 peut =EAtre consid=E9r=E9 comme non cassable. Peut-on
dire que si les blocs chiffr=E9s sont al=E9atoires vis-=E0-vis des blocs =
=E0
chiffrer, il est illusoire de pouvoir casser la clef par une
cryptanalyse diff=E9rentielle ou lin=E9aire? c'est pr=E9cis=E9ment =E0 ce n=
iveau
que les opinions m'int=E9ressent.
Le cryptosyst=E8me exp=E9rimental classicsys est de nouveau op=E9rationnel.
Le serveur avait rendu l'=E2me apr=E8s 13 ans de bons et loyaux services.
Le but que je poursuis est de montrer la faisabilit=E9 d'un tel projet.
Voir:
www.ulb.ac.be/di/scsi/classicsys/experim.htm
j'arrive pas a lire le document (j'ai firefox... c'est peut être ca)... le RTF je devrais arriver a le lire...
Il se peut que le texte a été effacé. Le site hébergeur le
maintient en place que pendant 21 jours. Le texte a été remis en place aujourd'hui. Le lien a été créé: http://cjoint.com/?iBlp7RPPn0
Bien à vous.
Emile
Alain
effectivement, et en pdf en plus 8)
ca a l'air de se tenir, mais je n'ai pas le niveau pour comprendre tout en lecture rapide ;-)
quelques point à surveiller : - être apparemment aléatoire pour une entrée non aléatoire est nécessaire pour un bon algo de chiffrement bijectif (tout comme pour un compresseur, qui ne chiffre pas), mais pas suffisant - avoir des moments (moyenne, variance...) identiques à du bruit n'indique pas que c'est un bruit. il peut y avoir des corrélation simples qui échappent au moment classiques... d'ailleurs c'est un problème insoluble. de toute facon ce n'est pas de l'aléatoire, juste du déterministe dur à corréler par calcul
- j'ai pas tout compris sur la méthode. ca ressemble aux systèmes de logarithmes en corps fini, qui sont typiquement des systèmes à clé publique... or c'est comparé à AES... - si c'est une crypto asymétrique basé sur des logarithmen sur corps fini, le problème doit être bien connu... quelle comparaison par rapport aux courbes éliptiques ? plus rapide ou pas à solidité comparable ?
bon il faudrait que je lise plus avant, mais ca semble mieu se tenir que pas mal de trucs lu ici... je reste juste sceptique a propos des nouvelles idées dans ce domaine... on a une forte tendance à découvrir des trucs déja éventés...
On 26 août, 22:15, Alain wrote:
j'arrive pas a lire le document (j'ai firefox... c'est peut être ca)... le RTF je devrais arriver a le lire...
Il se peut que le texte a été effacé. Le site hébergeur le
maintient en place que pendant 21 jours. Le texte a été remis en place aujourd'hui. Le lien a été créé: http://cjoint.com/?iBlp7RPPn0
Bien à vous.
Emile
effectivement, et en pdf en plus 8)
ca a l'air de se tenir, mais je n'ai pas le niveau pour comprendre tout
en lecture rapide ;-)
quelques point à surveiller :
- être apparemment aléatoire pour une entrée non aléatoire est
nécessaire pour un bon algo de chiffrement bijectif (tout comme pour un
compresseur, qui ne chiffre pas), mais pas suffisant
- avoir des moments (moyenne, variance...) identiques à du bruit
n'indique pas que c'est un bruit. il peut y avoir des corrélation
simples qui échappent au moment classiques... d'ailleurs c'est un
problème insoluble. de toute facon ce n'est pas de l'aléatoire, juste du
déterministe dur à corréler par calcul
- j'ai pas tout compris sur la méthode. ca ressemble aux systèmes de
logarithmes en corps fini, qui sont typiquement des systèmes à clé
publique... or c'est comparé à AES...
- si c'est une crypto asymétrique basé sur des logarithmen sur corps
fini, le problème doit être bien connu... quelle comparaison par rapport
aux courbes éliptiques ? plus rapide ou pas à solidité comparable ?
bon il faudrait que je lise plus avant, mais ca semble mieu se tenir que
pas mal de trucs lu ici... je reste juste sceptique a propos des
nouvelles idées dans ce domaine... on a une forte tendance à découvrir
des trucs déja éventés...
On 26 août, 22:15, Alain <al...@no.ne.org> wrote:
j'arrive pas a lire le document (j'ai firefox... c'est peut être ca)...
le RTF je devrais arriver a le lire...
Il se peut que le texte a été effacé. Le site hébergeur le
maintient en place que pendant 21 jours. Le texte a été remis en place
aujourd'hui. Le lien a été créé: http://cjoint.com/?iBlp7RPPn0
ca a l'air de se tenir, mais je n'ai pas le niveau pour comprendre tout en lecture rapide ;-)
quelques point à surveiller : - être apparemment aléatoire pour une entrée non aléatoire est nécessaire pour un bon algo de chiffrement bijectif (tout comme pour un compresseur, qui ne chiffre pas), mais pas suffisant - avoir des moments (moyenne, variance...) identiques à du bruit n'indique pas que c'est un bruit. il peut y avoir des corrélation simples qui échappent au moment classiques... d'ailleurs c'est un problème insoluble. de toute facon ce n'est pas de l'aléatoire, juste du déterministe dur à corréler par calcul
- j'ai pas tout compris sur la méthode. ca ressemble aux systèmes de logarithmes en corps fini, qui sont typiquement des systèmes à clé publique... or c'est comparé à AES... - si c'est une crypto asymétrique basé sur des logarithmen sur corps fini, le problème doit être bien connu... quelle comparaison par rapport aux courbes éliptiques ? plus rapide ou pas à solidité comparable ?
bon il faudrait que je lise plus avant, mais ca semble mieu se tenir que pas mal de trucs lu ici... je reste juste sceptique a propos des nouvelles idées dans ce domaine... on a une forte tendance à découvrir des trucs déja éventés...
On 26 août, 22:15, Alain wrote:
j'arrive pas a lire le document (j'ai firefox... c'est peut être ca)... le RTF je devrais arriver a le lire...
Il se peut que le texte a été effacé. Le site hébergeur le
maintient en place que pendant 21 jours. Le texte a été remis en place aujourd'hui. Le lien a été créé: http://cjoint.com/?iBlp7RPPn0
Bien à vous.
Emile
Emile
On 27 août, 22:52, Alain wrote:
effectivement, et en pdf en plus 8)
ca a l'air de se tenir, mais je n'ai pas le niveau pour comprendre tout en lecture rapide ;-) Pas de problèmes, je pourrai vous aider
Il se peut que le texte aie été effacé. Le site hébergeur le maintient en place que pendant 21 jours. Le texte a été remis en pl ace aujourd'hui. Le lien a été créé:http://cjoint.com/?iBlp7RPPn0
Comme je l'ai déjà dit précédemment, mon but n'est pas de réalis er un générateur de nombres aléatoires qui ne pourrait pas être mis en défaut, même avec les moyens les plus sophistiqués, mais plutôt de faire connaitre les caractéristiques de l'algorithme SED éventuellement par le biais des nombres aléatoires.
Si l'on examine la grandeur des boites de substitution des algorithmes les plus connus, les boites du DES sont constitués de 4 bits et tandis que ceux de l'AES sont de 32 bits. On a tout intérêt à adopter une boite de grandeur égale à celles des blocs à chiffrer ou à déchiffrer. C'est ce que réalise l'algorithme SED, probablement le seul.
L'avantage premier du SED est de pouvoir réaliser des simulations de l'algorithme avec des grandeurs de boîtes 7 ou de 17 bits, car pour ces deux valeurs, il est possible de disposer des structures de corps finis ayant des bases différentes et de pratiquer une exploration exhaustive. Si le générateur de nombres aléatoires est correct, il en sera de même de l'algorithme qui le réalise. Il n'est pas possible de réaliser des simulations à l'aide de petits blocs avec l'AES.
Supposons un générateur qui crée des nombres aléatoires formés d e "n" bits. Vous avez dans ce cas la possibilité de créer 2^n nombres différents. Si vous faites 2^n tirages, la moyenne pour chaque nombre sera de "1" et la distribution des probabilités du nombre des résultats pour chacun des 2^n-1 nombres sera donnée par la loi de distribution de Poisson. Pour "n" égal à 7 ou 17, il est possible d'exécuter 2^n-1 tirages et de pouvoir comparer les résultats expérimentaux aux valeurs théoriques. C'est ce qui a été fait et les conclusions pour n=7 et 17 seront également valables pour n7. Il y aurait encore une possibilité de réaliser une simulation avec n1, ce qui ne pourrait que confirmer les résultats qu'on devrait obtenir avec n7, mais pour cela il faudrait faire usage d'un fichier avec la possibilité de lire et d'écrire dans les 2147483647 octets du fichier, chacun des octets étant pris individuellement.
Je vous invite à tester sur votre PC le crypto-système expérimental Classicsys qui fait usage de l'algorithme SED (www.ulb.ac.be/di/scsi/ classicsys/experim.htm). Vous pouvez prendre deux affiliations, par exemple comme particulier et indépendant et correspondre de l'une à l'autre, le système prend en charge la gestion des clefs.
Je serai absent jusqu'au 6 octobre.
Emile
On 27 août, 22:52, Alain <al...@no.ne.org> wrote:
effectivement, et en pdf en plus 8)
ca a l'air de se tenir, mais je n'ai pas le niveau pour comprendre tout
en lecture rapide ;-)
Pas de problèmes, je pourrai vous aider
Il se peut que le texte aie été effacé. Le site hébergeur le
maintient en place que pendant 21 jours. Le texte a été remis en pl ace
aujourd'hui. Le lien a été créé:http://cjoint.com/?iBlp7RPPn0
Comme je l'ai déjà dit précédemment, mon but n'est pas de réalis er un
générateur de nombres aléatoires qui ne pourrait pas être mis en
défaut, même avec les moyens les plus sophistiqués, mais plutôt de
faire connaitre les caractéristiques de l'algorithme SED
éventuellement par le biais des nombres aléatoires.
Si l'on examine la grandeur des boites de substitution des
algorithmes les plus connus, les boites du DES sont constitués de 4
bits et tandis que ceux de l'AES sont de 32 bits. On a tout intérêt à
adopter une boite de grandeur égale à celles des blocs à chiffrer ou à
déchiffrer. C'est ce que réalise l'algorithme SED, probablement le
seul.
L'avantage premier du SED est de pouvoir réaliser des simulations de
l'algorithme avec des grandeurs de boîtes 7 ou de 17 bits, car pour
ces deux valeurs, il est possible de disposer des structures de corps
finis ayant des bases différentes et de pratiquer une exploration
exhaustive. Si le générateur de nombres aléatoires est correct, il en
sera de même de l'algorithme qui le réalise. Il n'est pas possible de
réaliser des simulations à l'aide de petits blocs avec l'AES.
Supposons un générateur qui crée des nombres aléatoires formés d e "n"
bits. Vous avez dans ce cas la possibilité de créer 2^n nombres
différents. Si vous faites 2^n tirages, la moyenne pour chaque nombre
sera de "1" et la distribution des probabilités du nombre des
résultats pour chacun des 2^n-1 nombres sera donnée par la loi de
distribution de Poisson. Pour "n" égal à 7 ou 17, il est possible
d'exécuter 2^n-1 tirages et de pouvoir comparer les résultats
expérimentaux aux valeurs théoriques. C'est ce qui a été fait et les
conclusions pour n=7 et 17 seront également valables pour n=127. Il y
aurait encore une possibilité de réaliser une simulation avec n=31, ce
qui ne pourrait que confirmer les résultats qu'on devrait obtenir avec
n=127, mais pour cela il faudrait faire usage d'un fichier avec la
possibilité de lire et d'écrire dans les 2147483647 octets du fichier,
chacun des octets étant pris individuellement.
Je vous invite à tester sur votre PC le crypto-système expérimental
Classicsys qui fait usage de l'algorithme SED (www.ulb.ac.be/di/scsi/
classicsys/experim.htm). Vous pouvez prendre deux affiliations, par
exemple comme particulier et indépendant et correspondre de l'une à
l'autre, le système prend en charge la gestion des clefs.
ca a l'air de se tenir, mais je n'ai pas le niveau pour comprendre tout en lecture rapide ;-) Pas de problèmes, je pourrai vous aider
Il se peut que le texte aie été effacé. Le site hébergeur le maintient en place que pendant 21 jours. Le texte a été remis en pl ace aujourd'hui. Le lien a été créé:http://cjoint.com/?iBlp7RPPn0
Comme je l'ai déjà dit précédemment, mon but n'est pas de réalis er un générateur de nombres aléatoires qui ne pourrait pas être mis en défaut, même avec les moyens les plus sophistiqués, mais plutôt de faire connaitre les caractéristiques de l'algorithme SED éventuellement par le biais des nombres aléatoires.
Si l'on examine la grandeur des boites de substitution des algorithmes les plus connus, les boites du DES sont constitués de 4 bits et tandis que ceux de l'AES sont de 32 bits. On a tout intérêt à adopter une boite de grandeur égale à celles des blocs à chiffrer ou à déchiffrer. C'est ce que réalise l'algorithme SED, probablement le seul.
L'avantage premier du SED est de pouvoir réaliser des simulations de l'algorithme avec des grandeurs de boîtes 7 ou de 17 bits, car pour ces deux valeurs, il est possible de disposer des structures de corps finis ayant des bases différentes et de pratiquer une exploration exhaustive. Si le générateur de nombres aléatoires est correct, il en sera de même de l'algorithme qui le réalise. Il n'est pas possible de réaliser des simulations à l'aide de petits blocs avec l'AES.
Supposons un générateur qui crée des nombres aléatoires formés d e "n" bits. Vous avez dans ce cas la possibilité de créer 2^n nombres différents. Si vous faites 2^n tirages, la moyenne pour chaque nombre sera de "1" et la distribution des probabilités du nombre des résultats pour chacun des 2^n-1 nombres sera donnée par la loi de distribution de Poisson. Pour "n" égal à 7 ou 17, il est possible d'exécuter 2^n-1 tirages et de pouvoir comparer les résultats expérimentaux aux valeurs théoriques. C'est ce qui a été fait et les conclusions pour n=7 et 17 seront également valables pour n7. Il y aurait encore une possibilité de réaliser une simulation avec n1, ce qui ne pourrait que confirmer les résultats qu'on devrait obtenir avec n7, mais pour cela il faudrait faire usage d'un fichier avec la possibilité de lire et d'écrire dans les 2147483647 octets du fichier, chacun des octets étant pris individuellement.
Je vous invite à tester sur votre PC le crypto-système expérimental Classicsys qui fait usage de l'algorithme SED (www.ulb.ac.be/di/scsi/ classicsys/experim.htm). Vous pouvez prendre deux affiliations, par exemple comme particulier et indépendant et correspondre de l'une à l'autre, le système prend en charge la gestion des clefs.
