Proposition : cryptage pyramidale

Klopfenstein Michaël

22/11/2003 à 00:32

Bonjour,

Par curiosité j'ai jeté un oeil rapide à votre algorihtme, je ne suis pas
entré dans le détails des logarthimes discret. Mais une première chose à
tout de suite heurté ma compréhension :

Si j'ai bien compris la clé de cryptage et la clé inverse vérifient la
relation : K*K' = 1 modulo (2^127-1)

Mais alors connaissant K qui est une clé publique de cryptage, il devient
élémentaire de trouver K' :
le groupe des inversible de Z/(2^127-1)Z possède un ordre diviseur de son
nombre d'élément 2^127-2
puisque 2^127-2 est premier il suffit d'elever K à la puissance 2^127-3
modulo(2^127-1) pour trouver K',
Cela est fait en une centaine de multiplication.

Exemple : la clé inverse de 1121352215277747566355846511240281621 est le
nombre
54120172486147719549652715001817468382 (1/300 ème de seconde de calcul)

Si la clé privée de décryptage se calcule aussi facilement, est-ce une clé
privée ?
Peut-être n'ai-je pas compris quelque chose?

Pierre Vandevennne

22/11/2003 à 00:59

"Emile Musyck" wrote in
news:3fbe80f0$0$22028$:

c'est effectivement étonnant que durant des années des ténors du
groupe se soit /amusés/ avec un truc pas trop mathématique et que là,
un système semble-t-il proprement spécifié, gorgé de logarithme
discret et de vecteurs tarabiscotés, n'intéresse pas davantage...

La réponse est dans la question: dans le premier cas, c'est amusant.
Dans le second, il faut se casser la tête, tête unique qu'on se casse
déjà au boulot...

Je crains que le groupe "fr.misc.cryptologie" ne me permettra pas
de trouver le correspondant pour un dialogue relatif à la
robustesse de l'algorithme mais bien peut-être pour un test de la
convivialité de ClassicSys.

Je crois que cette vue un peu hautaine est un peu déplacée. Je suis
certain que des personnes comme François Grieu, Thomas Pornin et
d'autres contributeurs que j'oublie disposent de tout le bagage
mathématique nécessaire, mais j'imagine qu'ils ont d'autres choses à
faire.

En ce qui me concerne (chacun son truc) il me suffit de savoir que même
si ces algorithmes étaient parfaits, il est très probable qu'il serait
relativement aisé d'exploser leurs implémentations pratiques.

ClassicSys me parait impressionant. Trop, peut-être.

Quant à l'algorithme de M. Klopfenstein, j'ai lu l'"avertissement" et ai
décidé que puisque à priori M.K. ne voulait pas que je regarde, je ne
regarde pas.

Même Neil Koblitz est nettement plus hospitalier. ;-)

L'idéal pour se faire connaître, se sont des tribunes comme Eurocrypt
ou Crypto, malheureusement, je n'ai plus l'âge de courir ce genre de
réunions. Et puis, il faut être pistonné par les habitués de ces
réunions. Je souhaite pour Michaël que le professeur Mignotte de
Strasbourg prendra son poulain sous sa protection au prochain
Eurocrypt.

Ma sympathie. C'est toujours la même chose. J'aime de temps en temps
rappeller ce qu'un de mes Prof d'Univ me dit un jour (dans les années
80) : "Monsieur Vandevenne, si vous pensez que les ordinateurs seont un
jour autre chose que de grosses calculatrices, vous vous trompez
lourdement"

(il n'y a qu'un Prof d'Univ qui peut trouver la bonne intonation pour
dire "vous vous trompez lourdement" - le glas sonne dans le lointain)

-soit tu n'as pas crié assez fort à l'incassabilité de
SED/ClassicSys,
Si quelqu'un a compris le papier de Mieczislaw, il en sera

persuadé.

Pas d'accord.

D'abord d'un point de vue purement réthorique: cette phrase implique que
si on n'est pas persuadé de l'incassabilité de ClassicSys et qu'on a lu
ce papier, on ne l'a pas compris. C'est un peu simple, et cela enlève
beaucoup d'intérêt au débat. Que pense Mieczislaw de ClassicSys au fait?
;-)

Ensuite, d'un point de vue réaliste. Si je ne lis qu'un papier sur les
techniques de factorisation des grands nombres et que je le comprends,
je peux facilement me convaincre de l'inviolabilité de clés de 384 bits.
Cela ne prouve rien. L'intérêt du RSA est justement la connexion
généralement admise avec un problème relativement simple.

-soit tu es arrivés trop tard, les amateurs se sont lassés...

La crypto n'a plus tellement la cote. Les grandes manoeuvres politico-
civiques sont terminées, le combat pour la sécurité informatique a été
gagné d'un point de vue crypto et perdu sur d'autres fronts et, en plus,
les algorithmes pleuvent, sans qu'ils répondent vraiment à une besoin.

Classicsys pourrait, si l'on en admet la solidité, remplacer certains
protocoles complexes reposant actuellement sur le RSA mais ce que
Monsieur Musyk présente comme un avantage est en fait un inconvénient:
il n'y a pas énormément de cryptographes professionnels qui vont
s'intéresser à un système qui prive les majors du domaine de revenus.
:-)

-soit ton invention n'apporte rien mais je pense qu'il y'aurait bien
eu quelqu'un de compétent pour le dire, même poliment.

je pense pouvoir affirmer que personne ne pense "ridicule" - c'est sans
aucun doute un bel effort, on le respecte et puis on retourne
travailler.

Le SED est l'unique algorithme asymétrique à clefs privées qui
soit.

Certaines personnes peuvent penser qu'on ajoute une limitation des
algorithmes symétriques à un algorithme asymétrique. It's in the eye of
the beholder.

L'enfouissement cet l'algorithme dans un circuit intégré lui
permettrait d'effectuer toutes les possibilités du RSA, mais avec une
vitesse de chiffrement plus de 1000 fois supérieure, et avec une
gestion des clefs réduite à sa plus simple. Chez Verisign,
l'hébergement de la clef publique ne coûte que 1300 Euros et après
quelque temps, on vous invite à la remplacer (en la payant
évidemment). Avez vous déjà vu une clef qui s'use en l'utilisant...

Donc Verisign et les autres ne vont pas s'intéresser à Classicsys.

Certainement pas avec Classicsys et de plus elle est free.
-soit ton site manque de fond noir et de couleur kifonmalozyeu.
Bonne suggestion.

Ah, encore une pique. On peut aussi parler de l'orthographe? :-O

-soit tes logarithmes sont trop discrets... je sais pas moi...
Je crois que l'adjectif "discret" effraie le lecteur. Discret veut

seulement dire
par valeur entière, à ne pas confondre avec les logarithmes décimaux
ou naturels.

Non, je vous assure que discret, c'est très bien perçu en crypto. Le
décimal, c'est d'une telle banalité. Quant au logarithme "naturel", fils
illégitime de Mr Neper, il n'y a plus guère que José Bové qui le défend.

Fluctuat nec mergitur

Timeo doli frangentur inanes

"Emile Musyck" <emilemusyck@skynet.be> wrote in
news:3fbe80f0$0$22028$ba620e4c@reader3.news.skynet.be:

c'est effectivement étonnant que durant des années des ténors du
groupe se soit /amusés/ avec un truc pas trop mathématique et que là,
un système semble-t-il proprement spécifié, gorgé de logarithme
discret et de vecteurs tarabiscotés, n'intéresse pas davantage...

La réponse est dans la question: dans le premier cas, c'est amusant.
Dans le second, il faut se casser la tête, tête unique qu'on se casse
déjà au boulot...

Je crains que le groupe "fr.misc.cryptologie" ne me permettra pas
de trouver le correspondant pour un dialogue relatif à la
robustesse de l'algorithme mais bien peut-être pour un test de la
convivialité de ClassicSys.

Je crois que cette vue un peu hautaine est un peu déplacée. Je suis
certain que des personnes comme François Grieu, Thomas Pornin et
d'autres contributeurs que j'oublie disposent de tout le bagage
mathématique nécessaire, mais j'imagine qu'ils ont d'autres choses à
faire.

En ce qui me concerne (chacun son truc) il me suffit de savoir que même
si ces algorithmes étaient parfaits, il est très probable qu'il serait
relativement aisé d'exploser leurs implémentations pratiques.

ClassicSys me parait impressionant. Trop, peut-être.

Quant à l'algorithme de M. Klopfenstein, j'ai lu l'"avertissement" et ai
décidé que puisque à priori M.K. ne voulait pas que je regarde, je ne
regarde pas.

Même Neil Koblitz est nettement plus hospitalier. ;-)

L'idéal pour se faire connaître, se sont des tribunes comme Eurocrypt
ou Crypto, malheureusement, je n'ai plus l'âge de courir ce genre de
réunions. Et puis, il faut être pistonné par les habitués de ces
réunions. Je souhaite pour Michaël que le professeur Mignotte de
Strasbourg prendra son poulain sous sa protection au prochain
Eurocrypt.

Ma sympathie. C'est toujours la même chose. J'aime de temps en temps
rappeller ce qu'un de mes Prof d'Univ me dit un jour (dans les années
80) : "Monsieur Vandevenne, si vous pensez que les ordinateurs seont un
jour autre chose que de grosses calculatrices, vous vous trompez
lourdement"

(il n'y a qu'un Prof d'Univ qui peut trouver la bonne intonation pour
dire "vous vous trompez lourdement" - le glas sonne dans le lointain)

-soit tu n'as pas crié assez fort à l'incassabilité de
SED/ClassicSys,
Si quelqu'un a compris le papier de Mieczislaw, il en sera

persuadé.

Pas d'accord.

D'abord d'un point de vue purement réthorique: cette phrase implique que
si on n'est pas persuadé de l'incassabilité de ClassicSys et qu'on a lu
ce papier, on ne l'a pas compris. C'est un peu simple, et cela enlève
beaucoup d'intérêt au débat. Que pense Mieczislaw de ClassicSys au fait?
;-)

Ensuite, d'un point de vue réaliste. Si je ne lis qu'un papier sur les
techniques de factorisation des grands nombres et que je le comprends,
je peux facilement me convaincre de l'inviolabilité de clés de 384 bits.
Cela ne prouve rien. L'intérêt du RSA est justement la connexion
généralement admise avec un problème relativement simple.

-soit tu es arrivés trop tard, les amateurs se sont lassés...

La crypto n'a plus tellement la cote. Les grandes manoeuvres politico-
civiques sont terminées, le combat pour la sécurité informatique a été
gagné d'un point de vue crypto et perdu sur d'autres fronts et, en plus,
les algorithmes pleuvent, sans qu'ils répondent vraiment à une besoin.

Classicsys pourrait, si l'on en admet la solidité, remplacer certains
protocoles complexes reposant actuellement sur le RSA mais ce que
Monsieur Musyk présente comme un avantage est en fait un inconvénient:
il n'y a pas énormément de cryptographes professionnels qui vont
s'intéresser à un système qui prive les majors du domaine de revenus.
:-)

-soit ton invention n'apporte rien mais je pense qu'il y'aurait bien
eu quelqu'un de compétent pour le dire, même poliment.

je pense pouvoir affirmer que personne ne pense "ridicule" - c'est sans
aucun doute un bel effort, on le respecte et puis on retourne
travailler.

Le SED est l'unique algorithme asymétrique à clefs privées qui
soit.

Certaines personnes peuvent penser qu'on ajoute une limitation des
algorithmes symétriques à un algorithme asymétrique. It's in the eye of
the beholder.

L'enfouissement cet l'algorithme dans un circuit intégré lui
permettrait d'effectuer toutes les possibilités du RSA, mais avec une
vitesse de chiffrement plus de 1000 fois supérieure, et avec une
gestion des clefs réduite à sa plus simple. Chez Verisign,
l'hébergement de la clef publique ne coûte que 1300 Euros et après
quelque temps, on vous invite à la remplacer (en la payant
évidemment). Avez vous déjà vu une clef qui s'use en l'utilisant...

Donc Verisign et les autres ne vont pas s'intéresser à Classicsys.

Certainement pas avec Classicsys et de plus elle est free.

-soit ton site manque de fond noir et de couleur kifonmalozyeu.
Bonne suggestion.

Ah, encore une pique. On peut aussi parler de l'orthographe? :-O

-soit tes logarithmes sont trop discrets... je sais pas moi...
Je crois que l'adjectif "discret" effraie le lecteur. Discret veut

seulement dire
par valeur entière, à ne pas confondre avec les logarithmes décimaux
ou naturels.

Non, je vous assure que discret, c'est très bien perçu en crypto. Le
décimal, c'est d'une telle banalité. Quant au logarithme "naturel", fils
illégitime de Mr Neper, il n'y a plus guère que José Bové qui le défend.

Fluctuat nec mergitur

Timeo doli frangentur inanes

Vous avez filtré cet utilisateur ! Consultez son message

"Emile Musyck" wrote in
news:3fbe80f0$0$22028$:

c'est effectivement étonnant que durant des années des ténors du
groupe se soit /amusés/ avec un truc pas trop mathématique et que là,
un système semble-t-il proprement spécifié, gorgé de logarithme
discret et de vecteurs tarabiscotés, n'intéresse pas davantage...

La réponse est dans la question: dans le premier cas, c'est amusant.
Dans le second, il faut se casser la tête, tête unique qu'on se casse
déjà au boulot...

Je crains que le groupe "fr.misc.cryptologie" ne me permettra pas
de trouver le correspondant pour un dialogue relatif à la
robustesse de l'algorithme mais bien peut-être pour un test de la
convivialité de ClassicSys.

Je crois que cette vue un peu hautaine est un peu déplacée. Je suis
certain que des personnes comme François Grieu, Thomas Pornin et
d'autres contributeurs que j'oublie disposent de tout le bagage
mathématique nécessaire, mais j'imagine qu'ils ont d'autres choses à
faire.

En ce qui me concerne (chacun son truc) il me suffit de savoir que même
si ces algorithmes étaient parfaits, il est très probable qu'il serait
relativement aisé d'exploser leurs implémentations pratiques.

ClassicSys me parait impressionant. Trop, peut-être.

Quant à l'algorithme de M. Klopfenstein, j'ai lu l'"avertissement" et ai
décidé que puisque à priori M.K. ne voulait pas que je regarde, je ne
regarde pas.

Même Neil Koblitz est nettement plus hospitalier. ;-)

L'idéal pour se faire connaître, se sont des tribunes comme Eurocrypt
ou Crypto, malheureusement, je n'ai plus l'âge de courir ce genre de
réunions. Et puis, il faut être pistonné par les habitués de ces
réunions. Je souhaite pour Michaël que le professeur Mignotte de
Strasbourg prendra son poulain sous sa protection au prochain
Eurocrypt.

Ma sympathie. C'est toujours la même chose. J'aime de temps en temps
rappeller ce qu'un de mes Prof d'Univ me dit un jour (dans les années
80) : "Monsieur Vandevenne, si vous pensez que les ordinateurs seont un
jour autre chose que de grosses calculatrices, vous vous trompez
lourdement"

(il n'y a qu'un Prof d'Univ qui peut trouver la bonne intonation pour
dire "vous vous trompez lourdement" - le glas sonne dans le lointain)

-soit tu n'as pas crié assez fort à l'incassabilité de
SED/ClassicSys,
Si quelqu'un a compris le papier de Mieczislaw, il en sera

persuadé.

Pas d'accord.

D'abord d'un point de vue purement réthorique: cette phrase implique que
si on n'est pas persuadé de l'incassabilité de ClassicSys et qu'on a lu
ce papier, on ne l'a pas compris. C'est un peu simple, et cela enlève
beaucoup d'intérêt au débat. Que pense Mieczislaw de ClassicSys au fait?
;-)

Ensuite, d'un point de vue réaliste. Si je ne lis qu'un papier sur les
techniques de factorisation des grands nombres et que je le comprends,
je peux facilement me convaincre de l'inviolabilité de clés de 384 bits.
Cela ne prouve rien. L'intérêt du RSA est justement la connexion
généralement admise avec un problème relativement simple.

-soit tu es arrivés trop tard, les amateurs se sont lassés...

La crypto n'a plus tellement la cote. Les grandes manoeuvres politico-
civiques sont terminées, le combat pour la sécurité informatique a été
gagné d'un point de vue crypto et perdu sur d'autres fronts et, en plus,
les algorithmes pleuvent, sans qu'ils répondent vraiment à une besoin.

Classicsys pourrait, si l'on en admet la solidité, remplacer certains
protocoles complexes reposant actuellement sur le RSA mais ce que
Monsieur Musyk présente comme un avantage est en fait un inconvénient:
il n'y a pas énormément de cryptographes professionnels qui vont
s'intéresser à un système qui prive les majors du domaine de revenus.
:-)

-soit ton invention n'apporte rien mais je pense qu'il y'aurait bien
eu quelqu'un de compétent pour le dire, même poliment.

je pense pouvoir affirmer que personne ne pense "ridicule" - c'est sans
aucun doute un bel effort, on le respecte et puis on retourne
travailler.

Le SED est l'unique algorithme asymétrique à clefs privées qui
soit.

Certaines personnes peuvent penser qu'on ajoute une limitation des
algorithmes symétriques à un algorithme asymétrique. It's in the eye of
the beholder.

L'enfouissement cet l'algorithme dans un circuit intégré lui
permettrait d'effectuer toutes les possibilités du RSA, mais avec une
vitesse de chiffrement plus de 1000 fois supérieure, et avec une
gestion des clefs réduite à sa plus simple. Chez Verisign,
l'hébergement de la clef publique ne coûte que 1300 Euros et après
quelque temps, on vous invite à la remplacer (en la payant
évidemment). Avez vous déjà vu une clef qui s'use en l'utilisant...

Donc Verisign et les autres ne vont pas s'intéresser à Classicsys.

Certainement pas avec Classicsys et de plus elle est free.
-soit ton site manque de fond noir et de couleur kifonmalozyeu.
Bonne suggestion.

Ah, encore une pique. On peut aussi parler de l'orthographe? :-O

-soit tes logarithmes sont trop discrets... je sais pas moi...
Je crois que l'adjectif "discret" effraie le lecteur. Discret veut

seulement dire
par valeur entière, à ne pas confondre avec les logarithmes décimaux
ou naturels.

Non, je vous assure que discret, c'est très bien perçu en crypto. Le
décimal, c'est d'une telle banalité. Quant au logarithme "naturel", fils
illégitime de Mr Neper, il n'y a plus guère que José Bové qui le défend.

Fluctuat nec mergitur

Timeo doli frangentur inanes

Klopfenstein Michaël

22/11/2003 à 01:32

Quant à l'algorithme de M. Klopfenstein, j'ai lu l'"avertissement" et ai
décidé que puisque à priori M.K. ne voulait pas que je regarde, je ne
regarde pas.

J'ai mis les sources en lignes.

Pierre Vandevennne

22/11/2003 à 04:08

"Klopfenstein Michaël" wrote in
news:bpmb0n$ocj$:

Quant à l'algorithme de M. Klopfenstein, j'ai lu l'"avertissement" et
ai

décidé que puisque à priori M.K. ne voulait pas que je regarde, je ne
regarde pas.

J'ai mis les sources en lignes.

Viens d'essayer le programme sur Candide de Voltaire.

Vitesse
-------

Fichier ASCII de 216 KB donne un fichier chiffré de 467 KB en 25
secondes sur un Pentium 3.0 GHZ, 2 GB RAM, 800 Mhz FSB., dual 120 GB en
SATA Raid 0.

C'est un peu plus du triple de la phase chiffrement d'un fichier
contenant des jpegs de 256 MB avec notre acrypt qui utilise un code
standard AES-128. A la grosse louche, et de façon optimiste,
l'algorithme est au _minimum_ 3000 à 4000 fois plus lent qu'AES
(acrypt met 30 secondes à lire et à zipper le fichier de 256 à 232MB -
ce n'est pas optimisé - 8 secondes à chiffrer et 3 secondes pour écrire
un AES optimisé devrait tourner à 70 MB/sec sur cette machine)

Randomisation
-------------

Le fichier chiffré se comprime de 20% - à priori, je n'aime pas du tout
cela, quoiqu'en faisant plus que doubler la taille, c'est peut être
acceptable. Difficile de faire des tests statistiques standards.

Déchiffrement
-------------

Cela marche! (sans rire - tous les algorithmes présentés ici ne passent
pas ce test ;-))

Code Source
-----------

No comment ;-)

Ah si, juste un petit truc, dans l'initialisation,

GetDir(0,curdir);
Open.InitialDir:=curdir;

et puis réutiliser pour la clé,

cela facilite grandement les test avec le programme installé bien au
chaud dans son petit répertoire tout à lui. Hardcoder la moitié du nom
de la clé dans le root de C n'est peut-être pas la meilleure chose à
faire.

Donc, avec une telle vitesse et un doublement de taille, je dirais
curiosité mathématique amusante.

remy

22/11/2003 à 16:22

On Fri, 21 Nov 2003 23:28:53 +0100, Klopfenstein Michaël wrote:

apres une lecture un peu plus attentive il y a un truc qui m echappe
dans ton pdf page 2 paragraphe c) shema de base
f( g(x),h(y) ) "=id"
somme (a(i,j) x^i y^j)
avec a(i,j) public

les fct g et h qui les construisent a priori c est celui qui envoie la
cle public mais celui qui veut crypter il n en a pas besoin ??

Les fonctions g et h sont des polynomes (de degré p-1) il ne faut pas
lire " g(x),h(y) " Mais " g(x)h(y) " C'est un produit ce qui donne un
polynome en deux variables. (Développé il s'exprime ave p²
coefficients.)
Intégré dans f, il donne le même type de polynomes à deux variables,
mais avec un p suffisant il devrait
être à l'abris de toute attaque. Donc f,g,h sont 3 fonctions qui servent
à définir les a(i,j)
Mais ces fonctions ne serve plus quand la forme est développée. Seul
l'ordinateur les a "onnu une fraction de seconde". Leur perte signifie
la définitive impossibilité de connaître le schéma de base factorisé par
quiconque. Or seule sa connaissance permetrait de casser la méthode.

il y a vraiment un truc qui m'echappe
tu ne veux pas nous/me pondre un petit fichier texte

mise en oeuvre pour etude d un cas contraire
nb premier 3,5 par exemple

merci a+ remy

Amethyste

22/11/2003 à 16:43

Vous devriez detailler davantage. En page 2 le procede de chiffrement n'est
vraiment pas clair.

En plus il doit y avoir une erreur d'indice dans la notation A indice 1,i
car en
developpant on voit que i varie de 1 a k et non de 1 a 2 puissance k

Quand au procede de "codage multiple" indique en page 1 il represente une
aubaine pour un decrypteur. En effet la donnee de Y1 Y2 represente une
double chance de reussir le decryptement ...

D'autre part il y a des indices de ce B. Schneier appelle du "snake oil", en
particulier le fait de creer des appellations "maison" pour des concepts
deja existants en cryptologie.

Ou encore la presence d'un grand nombre d'affirmations gratuites. Par
exemple
la taille d'un systeme a resoudre n'est pas forcement un obstacle dirimant
lors d'un decryptement, contrairement a ce que vous affirmez.

Bref je ne dis que le systeme est mauvais, je ne dis pas qu'il est bon, mais
j'affirme qu'en presentant les choses plus clairement, plus completement,
ca ferait gagner du temps a tout le monde.

WinTerMiNator

22/11/2003 à 18:08

"Pierre Vandevennne" a écrit dans le message de
news:

"Klopfenstein Michaël" wrote in
news:bpmb0n$ocj$:

Quant à l'algorithme de M. Klopfenstein, j'ai lu l'"avertissement" et
ai

décidé que puisque à priori M.K. ne voulait pas que je regarde, je ne
regarde pas.

J'ai mis les sources en lignes.

Viens d'essayer le programme sur Candide de Voltaire.

Vitesse
-------

Fichier ASCII de 216 KB donne un fichier chiffré de 467 KB en 25
secondes sur un Pentium 3.0 GHZ, 2 GB RAM, 800 Mhz FSB., dual 120 GB en
SATA Raid 0.

C'est un peu plus du triple de la phase chiffrement d'un fichier
contenant des jpegs de 256 MB avec notre acrypt qui utilise un code
standard AES-128. A la grosse louche, et de façon optimiste,
l'algorithme est au _minimum_ 3000 à 4000 fois plus lent qu'AES
(acrypt met 30 secondes à lire et à zipper le fichier de 256 à 232MB -
ce n'est pas optimisé - 8 secondes à chiffrer et 3 secondes pour écrire
un AES optimisé devrait tourner à 70 MB/sec sur cette machine)

Randomisation
-------------

Le fichier chiffré se comprime de 20% - à priori, je n'aime pas du tout
cela, quoiqu'en faisant plus que doubler la taille, c'est peut être
acceptable. Difficile de faire des tests statistiques standards.

Déchiffrement
-------------

Cela marche! (sans rire - tous les algorithmes présentés ici ne passent
pas ce test ;-))

Code Source
-----------

No comment ;-)

Ah si, juste un petit truc, dans l'initialisation,

GetDir(0,curdir);
Open.InitialDir:=curdir;

et puis réutiliser pour la clé,

cela facilite grandement les test avec le programme installé bien au
chaud dans son petit répertoire tout à lui. Hardcoder la moitié du nom
de la clé dans le root de C n'est peut-être pas la meilleure chose à
faire.

Donc, avec une telle vitesse et un doublement de taille, je dirais
curiosité mathématique amusante.

J'ai adressé en privé des remarques à M. Klopfenstein concernant son

chiffrement symétrique: les voici.

A) Fonctionnement hybride

- De manière générale, les cryptosystèmes à clé publique sont hybrides. Je
m'explique: pour des raisons de rapidité, voire d'infaisabilité technique,
on ne chiffre pas tout un document mais seulement une clé de chiffrement
"symétrique" avec une clé publique.

- Le processus est le suivant:
* Génération d'une clé aléatoire (avec un générateur matériel) ou
pseudo-aléatoire (avec un générateur logiciel) de qualité "crypto", c'est à
dire essentiellement imprévisible. Cette clé a de 128 à 256 bits, suivant
l'algorithme de chiffrement symétrique choisi. On l'appelle en général "clé
de session".
* Chiffrement du fichier avec la clé de session et l'algorithme
correspondant (3DES, conservateur; AES, moderne et rapide).
* Chiffrement de la clé de session avec la clé publique du destinataire.
* Mise en forme du résultat, concaténation du fichier chiffré et de la clé
de session chiffrée suivant un format préétabli.

- Au déchiffrement, le processus est inverse: avec sa clé privée, le
destinataire déchiffre la clé de session, puis avec la clé de session il
déchiffre le fichier.

- C'est ainsi que fonctionnent PGP, OpenPGP, S/MIME, SSL, OpenSSL etc.

- Si l'on en revient à "Pyramide", il y aurait plusieurs avantages à
procéder ainsi:
* Vous ne doublez plus la taille du fichier lors du chiffrement; si c'est
sans conséquence pour un petit fichier, cela peut être très pénalisant pour
un fichier de quelques centaines de MO.
* Le chiffrement est plus rapide: je crois qu'AES, qui a été conçu pour ça,
chiffrera beaucoup plus vite un gros fichier que Pyramide!
* Vous n'êtes pas obligé de vous limiter à F = E^2, mais vous pouvez
augmenter la sécurité de Pyramide avec F = E^n, où n = 3, 4, 5... En effet,
quintupler la taille de la clé de session en la chiffrant n'est pas
pénalisant: elle ne fait que de 128 à 256 bits.

B) Présentation de votre article

- Présenter votre article, c'est bien; la source du logiciel de chiffrement
"démo" que vous offrez en téléchargement, c'est mieux: outre des remarques
sur l'algo, vous pourrez aussi récolter des remarques judicieuses sur
l'implémentation logicielle et corriger d'éventuels défauts.

- Il faut impérativement une version anglaise de votre article!

- Pour intéresser le maximum de gens: programmation en ANSI C, d'une manière
indépendante de l'OS et du type de machine (et tant pis pour les interfaces
graphiques sous Windows. Plus tard!).

- Pour intéresser des cryptographes, ce qui est indispensable pour que votre
algo soit sérieusement étudié et ait une chance un jour d'être utilisé
(après plusieurs années d'études!), vous devez mettre en évidence ce qu'il
apporte par rapport à l'existant (RSA, El Gamal, ECC...), quels sont ses
avantages:
* rapidité?
* compacité (par exemple pour les ignatures électroniques)?
* peu gourmand en CPU, en mémoire, facilement implantable sur carte à puce?
* ...

- Vous devrez aussi vous livrer vous-même à des tentatives de cryptanalyse,
montrer que votre algorithme résiste aux attaques de base (cryptanalyse
différentielle; cryptanalyse linéaire), mais aussi à celles plus
hypothétiques (cryptanalyse par clair connu, clair choisi...), voire même
aux méthodes les plus récentes (cryptanalyse multivariable).

- C'est en fait en fonction de la qualité de votre travail et de la
profondeur de vos propres recherches que vous donnerez envie, ou pas, à des
cryptographes / cryptanalystes d'investir de leur temps dans l'étude de
votre algorithme!

- Ne vous découragez pas: vos titres universitaires doivent a priori vous
faire prendre au sérieux, mais n'étant pas vous même un cryptographe (donc
pas un expert du domaine), il serait peut-être bon de vous adresser d'abord
à un chercheur reconnu qui vous aidera à "déblayer le terrain" et vous dira
rapidement si votre travail doit être approfondi ou si ce n'est pas la peine
(défaut évident, voie déjà explorée et abandonnée etc.).

- La phase ultime et là aussi indispensable sera une publication dans une
revue internationale reconnue ou dans un congrès spécialisé, pratiquant la
revue d'article avant publication...

"Pierre Vandevennne" <pierre@datarescue_ns.com> a écrit dans le message de
news:Xns943B2A1F8A47Apierredatarescue@195.238.3.180...

"Klopfenstein Michaël" <m.klofpenstein@libertysurf.fr> wrote in
news:bpmb0n$ocj$1@news.tiscali.fr:

Quant à l'algorithme de M. Klopfenstein, j'ai lu l'"avertissement" et
ai

décidé que puisque à priori M.K. ne voulait pas que je regarde, je ne
regarde pas.

J'ai mis les sources en lignes.

Viens d'essayer le programme sur Candide de Voltaire.

Vitesse
-------

Fichier ASCII de 216 KB donne un fichier chiffré de 467 KB en 25
secondes sur un Pentium 3.0 GHZ, 2 GB RAM, 800 Mhz FSB., dual 120 GB en
SATA Raid 0.

C'est un peu plus du triple de la phase chiffrement d'un fichier
contenant des jpegs de 256 MB avec notre acrypt qui utilise un code
standard AES-128. A la grosse louche, et de façon optimiste,
l'algorithme est au _minimum_ 3000 à 4000 fois plus lent qu'AES
(acrypt met 30 secondes à lire et à zipper le fichier de 256 à 232MB -
ce n'est pas optimisé - 8 secondes à chiffrer et 3 secondes pour écrire
un AES optimisé devrait tourner à 70 MB/sec sur cette machine)

Randomisation
-------------

Le fichier chiffré se comprime de 20% - à priori, je n'aime pas du tout
cela, quoiqu'en faisant plus que doubler la taille, c'est peut être
acceptable. Difficile de faire des tests statistiques standards.

Déchiffrement
-------------

Cela marche! (sans rire - tous les algorithmes présentés ici ne passent
pas ce test ;-))

Code Source
-----------

No comment ;-)

Ah si, juste un petit truc, dans l'initialisation,

GetDir(0,curdir);
Open.InitialDir:=curdir;

et puis réutiliser pour la clé,

cela facilite grandement les test avec le programme installé bien au
chaud dans son petit répertoire tout à lui. Hardcoder la moitié du nom
de la clé dans le root de C n'est peut-être pas la meilleure chose à
faire.

Donc, avec une telle vitesse et un doublement de taille, je dirais
curiosité mathématique amusante.

J'ai adressé en privé des remarques à M. Klopfenstein concernant son

chiffrement symétrique: les voici.

A) Fonctionnement hybride

- De manière générale, les cryptosystèmes à clé publique sont hybrides. Je
m'explique: pour des raisons de rapidité, voire d'infaisabilité technique,
on ne chiffre pas tout un document mais seulement une clé de chiffrement
"symétrique" avec une clé publique.

- Le processus est le suivant:
* Génération d'une clé aléatoire (avec un générateur matériel) ou
pseudo-aléatoire (avec un générateur logiciel) de qualité "crypto", c'est à
dire essentiellement imprévisible. Cette clé a de 128 à 256 bits, suivant
l'algorithme de chiffrement symétrique choisi. On l'appelle en général "clé
de session".
* Chiffrement du fichier avec la clé de session et l'algorithme
correspondant (3DES, conservateur; AES, moderne et rapide).
* Chiffrement de la clé de session avec la clé publique du destinataire.
* Mise en forme du résultat, concaténation du fichier chiffré et de la clé
de session chiffrée suivant un format préétabli.

- Au déchiffrement, le processus est inverse: avec sa clé privée, le
destinataire déchiffre la clé de session, puis avec la clé de session il
déchiffre le fichier.

- C'est ainsi que fonctionnent PGP, OpenPGP, S/MIME, SSL, OpenSSL etc.

- Si l'on en revient à "Pyramide", il y aurait plusieurs avantages à
procéder ainsi:
* Vous ne doublez plus la taille du fichier lors du chiffrement; si c'est
sans conséquence pour un petit fichier, cela peut être très pénalisant pour
un fichier de quelques centaines de MO.
* Le chiffrement est plus rapide: je crois qu'AES, qui a été conçu pour ça,
chiffrera beaucoup plus vite un gros fichier que Pyramide!
* Vous n'êtes pas obligé de vous limiter à F = E^2, mais vous pouvez
augmenter la sécurité de Pyramide avec F = E^n, où n = 3, 4, 5... En effet,
quintupler la taille de la clé de session en la chiffrant n'est pas
pénalisant: elle ne fait que de 128 à 256 bits.

B) Présentation de votre article

- Présenter votre article, c'est bien; la source du logiciel de chiffrement
"démo" que vous offrez en téléchargement, c'est mieux: outre des remarques
sur l'algo, vous pourrez aussi récolter des remarques judicieuses sur
l'implémentation logicielle et corriger d'éventuels défauts.

- Il faut impérativement une version anglaise de votre article!

- Pour intéresser le maximum de gens: programmation en ANSI C, d'une manière
indépendante de l'OS et du type de machine (et tant pis pour les interfaces
graphiques sous Windows. Plus tard!).

- Pour intéresser des cryptographes, ce qui est indispensable pour que votre
algo soit sérieusement étudié et ait une chance un jour d'être utilisé
(après plusieurs années d'études!), vous devez mettre en évidence ce qu'il
apporte par rapport à l'existant (RSA, El Gamal, ECC...), quels sont ses
avantages:
* rapidité?
* compacité (par exemple pour les ignatures électroniques)?
* peu gourmand en CPU, en mémoire, facilement implantable sur carte à puce?
* ...

- Vous devrez aussi vous livrer vous-même à des tentatives de cryptanalyse,
montrer que votre algorithme résiste aux attaques de base (cryptanalyse
différentielle; cryptanalyse linéaire), mais aussi à celles plus
hypothétiques (cryptanalyse par clair connu, clair choisi...), voire même
aux méthodes les plus récentes (cryptanalyse multivariable).

- C'est en fait en fonction de la qualité de votre travail et de la
profondeur de vos propres recherches que vous donnerez envie, ou pas, à des
cryptographes / cryptanalystes d'investir de leur temps dans l'étude de
votre algorithme!

- Ne vous découragez pas: vos titres universitaires doivent a priori vous
faire prendre au sérieux, mais n'étant pas vous même un cryptographe (donc
pas un expert du domaine), il serait peut-être bon de vous adresser d'abord
à un chercheur reconnu qui vous aidera à "déblayer le terrain" et vous dira
rapidement si votre travail doit être approfondi ou si ce n'est pas la peine
(défaut évident, voie déjà explorée et abandonnée etc.).

- La phase ultime et là aussi indispensable sera une publication dans une
revue internationale reconnue ou dans un congrès spécialisé, pratiquant la
revue d'article avant publication...

Vous avez filtré cet utilisateur ! Consultez son message

"Pierre Vandevennne" a écrit dans le message de
news:

"Klopfenstein Michaël" wrote in
news:bpmb0n$ocj$:

Quant à l'algorithme de M. Klopfenstein, j'ai lu l'"avertissement" et
ai

décidé que puisque à priori M.K. ne voulait pas que je regarde, je ne
regarde pas.

J'ai mis les sources en lignes.

Viens d'essayer le programme sur Candide de Voltaire.

Vitesse
-------

Fichier ASCII de 216 KB donne un fichier chiffré de 467 KB en 25
secondes sur un Pentium 3.0 GHZ, 2 GB RAM, 800 Mhz FSB., dual 120 GB en
SATA Raid 0.

C'est un peu plus du triple de la phase chiffrement d'un fichier
contenant des jpegs de 256 MB avec notre acrypt qui utilise un code
standard AES-128. A la grosse louche, et de façon optimiste,
l'algorithme est au _minimum_ 3000 à 4000 fois plus lent qu'AES
(acrypt met 30 secondes à lire et à zipper le fichier de 256 à 232MB -
ce n'est pas optimisé - 8 secondes à chiffrer et 3 secondes pour écrire
un AES optimisé devrait tourner à 70 MB/sec sur cette machine)

Randomisation
-------------

Le fichier chiffré se comprime de 20% - à priori, je n'aime pas du tout
cela, quoiqu'en faisant plus que doubler la taille, c'est peut être
acceptable. Difficile de faire des tests statistiques standards.

Déchiffrement
-------------

Cela marche! (sans rire - tous les algorithmes présentés ici ne passent
pas ce test ;-))

Code Source
-----------

No comment ;-)

Ah si, juste un petit truc, dans l'initialisation,

GetDir(0,curdir);
Open.InitialDir:=curdir;

et puis réutiliser pour la clé,

cela facilite grandement les test avec le programme installé bien au
chaud dans son petit répertoire tout à lui. Hardcoder la moitié du nom
de la clé dans le root de C n'est peut-être pas la meilleure chose à
faire.

Donc, avec une telle vitesse et un doublement de taille, je dirais
curiosité mathématique amusante.

J'ai adressé en privé des remarques à M. Klopfenstein concernant son

chiffrement symétrique: les voici.

A) Fonctionnement hybride

- De manière générale, les cryptosystèmes à clé publique sont hybrides. Je
m'explique: pour des raisons de rapidité, voire d'infaisabilité technique,
on ne chiffre pas tout un document mais seulement une clé de chiffrement
"symétrique" avec une clé publique.

- Le processus est le suivant:
* Génération d'une clé aléatoire (avec un générateur matériel) ou
pseudo-aléatoire (avec un générateur logiciel) de qualité "crypto", c'est à
dire essentiellement imprévisible. Cette clé a de 128 à 256 bits, suivant
l'algorithme de chiffrement symétrique choisi. On l'appelle en général "clé
de session".
* Chiffrement du fichier avec la clé de session et l'algorithme
correspondant (3DES, conservateur; AES, moderne et rapide).
* Chiffrement de la clé de session avec la clé publique du destinataire.
* Mise en forme du résultat, concaténation du fichier chiffré et de la clé
de session chiffrée suivant un format préétabli.

- Au déchiffrement, le processus est inverse: avec sa clé privée, le
destinataire déchiffre la clé de session, puis avec la clé de session il
déchiffre le fichier.

- C'est ainsi que fonctionnent PGP, OpenPGP, S/MIME, SSL, OpenSSL etc.

- Si l'on en revient à "Pyramide", il y aurait plusieurs avantages à
procéder ainsi:
* Vous ne doublez plus la taille du fichier lors du chiffrement; si c'est
sans conséquence pour un petit fichier, cela peut être très pénalisant pour
un fichier de quelques centaines de MO.
* Le chiffrement est plus rapide: je crois qu'AES, qui a été conçu pour ça,
chiffrera beaucoup plus vite un gros fichier que Pyramide!
* Vous n'êtes pas obligé de vous limiter à F = E^2, mais vous pouvez
augmenter la sécurité de Pyramide avec F = E^n, où n = 3, 4, 5... En effet,
quintupler la taille de la clé de session en la chiffrant n'est pas
pénalisant: elle ne fait que de 128 à 256 bits.

B) Présentation de votre article

- Présenter votre article, c'est bien; la source du logiciel de chiffrement
"démo" que vous offrez en téléchargement, c'est mieux: outre des remarques
sur l'algo, vous pourrez aussi récolter des remarques judicieuses sur
l'implémentation logicielle et corriger d'éventuels défauts.

- Il faut impérativement une version anglaise de votre article!

- Pour intéresser le maximum de gens: programmation en ANSI C, d'une manière
indépendante de l'OS et du type de machine (et tant pis pour les interfaces
graphiques sous Windows. Plus tard!).

- Pour intéresser des cryptographes, ce qui est indispensable pour que votre
algo soit sérieusement étudié et ait une chance un jour d'être utilisé
(après plusieurs années d'études!), vous devez mettre en évidence ce qu'il
apporte par rapport à l'existant (RSA, El Gamal, ECC...), quels sont ses
avantages:
* rapidité?
* compacité (par exemple pour les ignatures électroniques)?
* peu gourmand en CPU, en mémoire, facilement implantable sur carte à puce?
* ...

- Vous devrez aussi vous livrer vous-même à des tentatives de cryptanalyse,
montrer que votre algorithme résiste aux attaques de base (cryptanalyse
différentielle; cryptanalyse linéaire), mais aussi à celles plus
hypothétiques (cryptanalyse par clair connu, clair choisi...), voire même
aux méthodes les plus récentes (cryptanalyse multivariable).

- C'est en fait en fonction de la qualité de votre travail et de la
profondeur de vos propres recherches que vous donnerez envie, ou pas, à des
cryptographes / cryptanalystes d'investir de leur temps dans l'étude de
votre algorithme!

- Ne vous découragez pas: vos titres universitaires doivent a priori vous
faire prendre au sérieux, mais n'étant pas vous même un cryptographe (donc
pas un expert du domaine), il serait peut-être bon de vous adresser d'abord
à un chercheur reconnu qui vous aidera à "déblayer le terrain" et vous dira
rapidement si votre travail doit être approfondi ou si ce n'est pas la peine
(défaut évident, voie déjà explorée et abandonnée etc.).

- La phase ultime et là aussi indispensable sera une publication dans une
revue internationale reconnue ou dans un congrès spécialisé, pratiquant la
revue d'article avant publication...

Pierre Vandevenne

23/11/2003 à 00:35

"WinTerMiNator" wrote in
news:3fbf97fb$0$6970$:

A) Fonctionnement hybride

- De manière générale, les cryptosystèmes à clé publique sont
hybrides. Je m'explique: pour des raisons de rapidité, voire
d'infaisabilité technique, on ne chiffre pas tout un document mais
seulement une clé de chiffrement "symétrique" avec une clé publique.

Sur ce point, mon opinion est la suivante: si MK place d'emblée des
barrières comme "non mathématiciens, non cryptographes vade-retro",
j'imagine qu'il est au courant de toutes ces "subtilités" (si j'ose dire)
et présente son algorithme dans la perspective de l'usage qu'il compte en
faire.

On peut aussi imaginer qu'il a lu au moins un ouvrage de cryptanalyse,
comme celui de Bauer.

Emile Musyck

23/11/2003 à 00:41

"Klopfenstein Michaël" a écrit dans le
message de news: bpm7fk$lcq$

Si j'ai bien compris la clé de cryptage et la clé inverse vérifient la
relation : K*K' = 1 modulo (2^127-1)

Exact, en fait l'algorithme SED est asymétrique mais à clefs privées.
Passer de K à K' est une fonction asymétrique. Le SED est également un
algorithme à clefs privées car si on connaît K, on connaît aussi K'.

Mais alors connaissant K qui est une clé publique de cryptage, il devient
élémentaire de trouver K' :

Évidemment, c'est élémentaire, Mr La Palice en dirait tout autant . Mais
avec ClassicSys, les choses sont plus subtiles. Alice reçoit du TA (TA=Trust
Authority = organisme de confiance) une clef privée de 128 bits et le TA
dispose de la clef inverse. Cette clef est en fait le résultat du
chiffrement du numéro d'affiliation d'Alice avec la clef secrète du TA.
Seuls le TA et Alice peuvent se correspondre avec un crypto système
asymétrique, mais 1000 fois plus rapide que le RSA. Alice demande au TA une
clef de session pour correspondre avec Bob en précisant le numéro
d'affiliation de Bob. A la réception du message d'Alice, le TA peut
recalculer la clef privée (K et K') de Bob. Le TA est en mesure de calculer
une clef de session d'Alice à Bob (résultat de chiffrement avec la clef
secrète du TA des numéros d'affiliation d'Alice et de Bob mis dans un même
bloc de 128 bits). Alice reçoit du TA plusieurs blocs qu'elle déchiffre tous
avec sa clef privée. (Plus exactement avec une clef particulière générée à
partir de sa clef privée.)
- Le premier bloc déchiffré par Alice donne la clef de session de
chiffrement d'Alice à Bob.
- Le deuxième bloc déchiffré donne en clair les numéros d'affiliation
des deux correspondants de la clef de session. Le logiciel de ClassicSys
effectue automatiquement la vérification si les numéros d'affiliation sont
exactes.
- Les troisième et quatrième blocs, déchiffrés par Alice, sont envoyés
dans le message d'Alice à Bob. Le déchiffrement de ces blocs par Bob à
l'aide de sa clef privée donnent en clair la clef de déchiffrement de
session
d'Alice à Bob et les numéros d'affiliation d'Alice et de Bob, ce qui permet
à Bob de prendre connaissance de l'expéditrice du message après la
vérification par le logiciel du numéro d'affiliation de Bob.
Alice peut envoyer un message chiffré à Bob à l'aide de l'algorithme
SED. Celui-ci chiffre des blocs de 128 bits avec des clefs de 128 bits
également à une vitesse semblable à celles des autres algorithmes
symétriques. Alice est seule capable de chiffrer avec la clef de session en
mode de chiffrement, tandis que Bob est seul capable de déchiffrer avec la
clef de déchiffrement. On se retrouve donc là dans des conditions semblables
à celles où Alice envoie un message chiffré RSA à Bob, ce message étant
chiffré à l'aide de la clef publique RSA de Bob et la clef secrète RSA
d'Alice. A la réception, Bob chiffre à l'aide de la clef publique RSA
d'Alice et ensuite à l'aide de sa clef secrète RSA. Ceci suppose qu'Alice et
Bob ont préalablement échangé leurs clefs publiques. Evidemment les
chiffrements s'effectuent 4000 fois moins vite, et encore il faut que les
modulos RSA des deux correspondants puissent s'adapter l'un l'autre. La
question de la vitesse du SED est un premier avantage, mais de plus, ce
n'est pas un crypto système hybride où on doit recourir à des algorithmes
différents comme le RSA et l'AES.

le groupe des inversible de Z/(2^127-1)Z possède un ordre diviseur de son
nombre d'élément 2^127-2
puisque 2^127-2 est premier il suffit d'élever K à la puissance 2^127-3
modulo(2^127-1) pour trouver K',
Cela est fait en une centaine de multiplication.
Exemple : la clé inverse de 1121352215277747566355846511240281621 est le
nombre

54120172486147719549652715001817468382 (1/300 ème de seconde de calcul)
Au début de ClassicSys, la clef SED inverse s'obtenait avec l'algorithme

d'Euclide quelque peu modifié, je suppose que vous voyez ce que je veux
dire. Depuis 1995 (je crois) l'inversion de clef s'opère suivant la méthode
que vous exposez. Je n'ai plus souvenance de la vitesse de l'inversion de la
clef, mais cela doit de cet ordre de grandeur là. Il faut tenir compte, que
dans un but de simplification, on a ajouté, un peu artificiellement, un
128ième bit aux 127 autres de manière à former des blocs de 128 bits
(128=2^7), ce qui facilite la programmation. Le logiciel ClassicSys des
utilisateurs ne comporte pas la fonction d'inversion des blocs de 128 bits.
Cette prérogative de la fonction d'inversion est seule l'apanage du logiciel
du TA.
En supposant qu'un jour, on puisse enfouir l'algorithme SED avec la clef
privée dans un circuit intégré et que le détenteur de ce circuit intégré est
incapable de connaître cette clef, à l'instar de ce qui se passe dans la
carte
SIM d'un GSM, les deux correspondants Alice et Bob sont incapables de
réaliser un faux message chiffré qui serait attribuable à l'autre
correspondant. Et même avec un ClassicSys tout software, il est parfaitement
possible de réaliser des é-mails recommandés, mais il faut faire intervenir
le TA, ne fusse que pour préciser d'une manière irréfutable les moments de
l'envoi et de la réception du é-mail recommandé. Mais ça, c'est encore un
peu de travail pour demain.

J'espère vous avoir éclairé un peu plus sur le SED et le système
ClassicSys, mais pour bien apprécier les finesses, rien de tel que de
prendre deux affiliations (identités réelles ou bidons, peu importe) et de
correspondre de l'une affiliation à l'autre.

Bien à vous,

Emile

PS. Une méthode didactique pour comprendre le RSA est d'effectuer une
simulation avec des petits nombres. Par exemple, p, q, N7 (*17),
on adopte e=7, on calcule d#, soit le message M, le message chiffré.
Tous ces calculs peuvent facilement s'effectuer à la main.
Pourrait-on faire une telle simulation avec votre cryptage pyramidale en
utilisant des petits nombres?

"Klopfenstein Michaël" <m.klofpenstein@libertysurf.fr> a écrit dans le
message de news: bpm7fk$lcq$1@news.tiscali.fr...

Si j'ai bien compris la clé de cryptage et la clé inverse vérifient la
relation : K*K' = 1 modulo (2^127-1)

Exact, en fait l'algorithme SED est asymétrique mais à clefs privées.
Passer de K à K' est une fonction asymétrique. Le SED est également un
algorithme à clefs privées car si on connaît K, on connaît aussi K'.

Mais alors connaissant K qui est une clé publique de cryptage, il devient
élémentaire de trouver K' :

Évidemment, c'est élémentaire, Mr La Palice en dirait tout autant . Mais
avec ClassicSys, les choses sont plus subtiles. Alice reçoit du TA (TA=Trust
Authority = organisme de confiance) une clef privée de 128 bits et le TA
dispose de la clef inverse. Cette clef est en fait le résultat du
chiffrement du numéro d'affiliation d'Alice avec la clef secrète du TA.
Seuls le TA et Alice peuvent se correspondre avec un crypto système
asymétrique, mais 1000 fois plus rapide que le RSA. Alice demande au TA une
clef de session pour correspondre avec Bob en précisant le numéro
d'affiliation de Bob. A la réception du message d'Alice, le TA peut
recalculer la clef privée (K et K') de Bob. Le TA est en mesure de calculer
une clef de session d'Alice à Bob (résultat de chiffrement avec la clef
secrète du TA des numéros d'affiliation d'Alice et de Bob mis dans un même
bloc de 128 bits). Alice reçoit du TA plusieurs blocs qu'elle déchiffre tous
avec sa clef privée. (Plus exactement avec une clef particulière générée à
partir de sa clef privée.)
- Le premier bloc déchiffré par Alice donne la clef de session de
chiffrement d'Alice à Bob.
- Le deuxième bloc déchiffré donne en clair les numéros d'affiliation
des deux correspondants de la clef de session. Le logiciel de ClassicSys
effectue automatiquement la vérification si les numéros d'affiliation sont
exactes.
- Les troisième et quatrième blocs, déchiffrés par Alice, sont envoyés
dans le message d'Alice à Bob. Le déchiffrement de ces blocs par Bob à
l'aide de sa clef privée donnent en clair la clef de déchiffrement de
session
d'Alice à Bob et les numéros d'affiliation d'Alice et de Bob, ce qui permet
à Bob de prendre connaissance de l'expéditrice du message après la
vérification par le logiciel du numéro d'affiliation de Bob.
Alice peut envoyer un message chiffré à Bob à l'aide de l'algorithme
SED. Celui-ci chiffre des blocs de 128 bits avec des clefs de 128 bits
également à une vitesse semblable à celles des autres algorithmes
symétriques. Alice est seule capable de chiffrer avec la clef de session en
mode de chiffrement, tandis que Bob est seul capable de déchiffrer avec la
clef de déchiffrement. On se retrouve donc là dans des conditions semblables
à celles où Alice envoie un message chiffré RSA à Bob, ce message étant
chiffré à l'aide de la clef publique RSA de Bob et la clef secrète RSA
d'Alice. A la réception, Bob chiffre à l'aide de la clef publique RSA
d'Alice et ensuite à l'aide de sa clef secrète RSA. Ceci suppose qu'Alice et
Bob ont préalablement échangé leurs clefs publiques. Evidemment les
chiffrements s'effectuent 4000 fois moins vite, et encore il faut que les
modulos RSA des deux correspondants puissent s'adapter l'un l'autre. La
question de la vitesse du SED est un premier avantage, mais de plus, ce
n'est pas un crypto système hybride où on doit recourir à des algorithmes
différents comme le RSA et l'AES.

le groupe des inversible de Z/(2^127-1)Z possède un ordre diviseur de son
nombre d'élément 2^127-2
puisque 2^127-2 est premier il suffit d'élever K à la puissance 2^127-3
modulo(2^127-1) pour trouver K',
Cela est fait en une centaine de multiplication.
Exemple : la clé inverse de 1121352215277747566355846511240281621 est le
nombre

54120172486147719549652715001817468382 (1/300 ème de seconde de calcul)
Au début de ClassicSys, la clef SED inverse s'obtenait avec l'algorithme

d'Euclide quelque peu modifié, je suppose que vous voyez ce que je veux
dire. Depuis 1995 (je crois) l'inversion de clef s'opère suivant la méthode
que vous exposez. Je n'ai plus souvenance de la vitesse de l'inversion de la
clef, mais cela doit de cet ordre de grandeur là. Il faut tenir compte, que
dans un but de simplification, on a ajouté, un peu artificiellement, un
128ième bit aux 127 autres de manière à former des blocs de 128 bits
(128=2^7), ce qui facilite la programmation. Le logiciel ClassicSys des
utilisateurs ne comporte pas la fonction d'inversion des blocs de 128 bits.
Cette prérogative de la fonction d'inversion est seule l'apanage du logiciel
du TA.
En supposant qu'un jour, on puisse enfouir l'algorithme SED avec la clef
privée dans un circuit intégré et que le détenteur de ce circuit intégré est
incapable de connaître cette clef, à l'instar de ce qui se passe dans la
carte
SIM d'un GSM, les deux correspondants Alice et Bob sont incapables de
réaliser un faux message chiffré qui serait attribuable à l'autre
correspondant. Et même avec un ClassicSys tout software, il est parfaitement
possible de réaliser des é-mails recommandés, mais il faut faire intervenir
le TA, ne fusse que pour préciser d'une manière irréfutable les moments de
l'envoi et de la réception du é-mail recommandé. Mais ça, c'est encore un
peu de travail pour demain.

J'espère vous avoir éclairé un peu plus sur le SED et le système
ClassicSys, mais pour bien apprécier les finesses, rien de tel que de
prendre deux affiliations (identités réelles ou bidons, peu importe) et de
correspondre de l'une affiliation à l'autre.

Bien à vous,

Emile

PS. Une méthode didactique pour comprendre le RSA est d'effectuer une
simulation avec des petits nombres. Par exemple, p, q, N7 (*17),
on adopte e=7, on calcule d#, soit le message M, le message chiffré.
Tous ces calculs peuvent facilement s'effectuer à la main.
Pourrait-on faire une telle simulation avec votre cryptage pyramidale en
utilisant des petits nombres?

Vous avez filtré cet utilisateur ! Consultez son message

"Klopfenstein Michaël" a écrit dans le
message de news: bpm7fk$lcq$

Si j'ai bien compris la clé de cryptage et la clé inverse vérifient la
relation : K*K' = 1 modulo (2^127-1)

Exact, en fait l'algorithme SED est asymétrique mais à clefs privées.
Passer de K à K' est une fonction asymétrique. Le SED est également un
algorithme à clefs privées car si on connaît K, on connaît aussi K'.

Mais alors connaissant K qui est une clé publique de cryptage, il devient
élémentaire de trouver K' :

Évidemment, c'est élémentaire, Mr La Palice en dirait tout autant . Mais
avec ClassicSys, les choses sont plus subtiles. Alice reçoit du TA (TA=Trust
Authority = organisme de confiance) une clef privée de 128 bits et le TA
dispose de la clef inverse. Cette clef est en fait le résultat du
chiffrement du numéro d'affiliation d'Alice avec la clef secrète du TA.
Seuls le TA et Alice peuvent se correspondre avec un crypto système
asymétrique, mais 1000 fois plus rapide que le RSA. Alice demande au TA une
clef de session pour correspondre avec Bob en précisant le numéro
d'affiliation de Bob. A la réception du message d'Alice, le TA peut
recalculer la clef privée (K et K') de Bob. Le TA est en mesure de calculer
une clef de session d'Alice à Bob (résultat de chiffrement avec la clef
secrète du TA des numéros d'affiliation d'Alice et de Bob mis dans un même
bloc de 128 bits). Alice reçoit du TA plusieurs blocs qu'elle déchiffre tous
avec sa clef privée. (Plus exactement avec une clef particulière générée à
partir de sa clef privée.)
- Le premier bloc déchiffré par Alice donne la clef de session de
chiffrement d'Alice à Bob.
- Le deuxième bloc déchiffré donne en clair les numéros d'affiliation
des deux correspondants de la clef de session. Le logiciel de ClassicSys
effectue automatiquement la vérification si les numéros d'affiliation sont
exactes.
- Les troisième et quatrième blocs, déchiffrés par Alice, sont envoyés
dans le message d'Alice à Bob. Le déchiffrement de ces blocs par Bob à
l'aide de sa clef privée donnent en clair la clef de déchiffrement de
session
d'Alice à Bob et les numéros d'affiliation d'Alice et de Bob, ce qui permet
à Bob de prendre connaissance de l'expéditrice du message après la
vérification par le logiciel du numéro d'affiliation de Bob.
Alice peut envoyer un message chiffré à Bob à l'aide de l'algorithme
SED. Celui-ci chiffre des blocs de 128 bits avec des clefs de 128 bits
également à une vitesse semblable à celles des autres algorithmes
symétriques. Alice est seule capable de chiffrer avec la clef de session en
mode de chiffrement, tandis que Bob est seul capable de déchiffrer avec la
clef de déchiffrement. On se retrouve donc là dans des conditions semblables
à celles où Alice envoie un message chiffré RSA à Bob, ce message étant
chiffré à l'aide de la clef publique RSA de Bob et la clef secrète RSA
d'Alice. A la réception, Bob chiffre à l'aide de la clef publique RSA
d'Alice et ensuite à l'aide de sa clef secrète RSA. Ceci suppose qu'Alice et
Bob ont préalablement échangé leurs clefs publiques. Evidemment les
chiffrements s'effectuent 4000 fois moins vite, et encore il faut que les
modulos RSA des deux correspondants puissent s'adapter l'un l'autre. La
question de la vitesse du SED est un premier avantage, mais de plus, ce
n'est pas un crypto système hybride où on doit recourir à des algorithmes
différents comme le RSA et l'AES.

le groupe des inversible de Z/(2^127-1)Z possède un ordre diviseur de son
nombre d'élément 2^127-2
puisque 2^127-2 est premier il suffit d'élever K à la puissance 2^127-3
modulo(2^127-1) pour trouver K',
Cela est fait en une centaine de multiplication.
Exemple : la clé inverse de 1121352215277747566355846511240281621 est le
nombre

54120172486147719549652715001817468382 (1/300 ème de seconde de calcul)
Au début de ClassicSys, la clef SED inverse s'obtenait avec l'algorithme

d'Euclide quelque peu modifié, je suppose que vous voyez ce que je veux
dire. Depuis 1995 (je crois) l'inversion de clef s'opère suivant la méthode
que vous exposez. Je n'ai plus souvenance de la vitesse de l'inversion de la
clef, mais cela doit de cet ordre de grandeur là. Il faut tenir compte, que
dans un but de simplification, on a ajouté, un peu artificiellement, un
128ième bit aux 127 autres de manière à former des blocs de 128 bits
(128=2^7), ce qui facilite la programmation. Le logiciel ClassicSys des
utilisateurs ne comporte pas la fonction d'inversion des blocs de 128 bits.
Cette prérogative de la fonction d'inversion est seule l'apanage du logiciel
du TA.
En supposant qu'un jour, on puisse enfouir l'algorithme SED avec la clef
privée dans un circuit intégré et que le détenteur de ce circuit intégré est
incapable de connaître cette clef, à l'instar de ce qui se passe dans la
carte
SIM d'un GSM, les deux correspondants Alice et Bob sont incapables de
réaliser un faux message chiffré qui serait attribuable à l'autre
correspondant. Et même avec un ClassicSys tout software, il est parfaitement
possible de réaliser des é-mails recommandés, mais il faut faire intervenir
le TA, ne fusse que pour préciser d'une manière irréfutable les moments de
l'envoi et de la réception du é-mail recommandé. Mais ça, c'est encore un
peu de travail pour demain.

J'espère vous avoir éclairé un peu plus sur le SED et le système
ClassicSys, mais pour bien apprécier les finesses, rien de tel que de
prendre deux affiliations (identités réelles ou bidons, peu importe) et de
correspondre de l'une affiliation à l'autre.

Bien à vous,

Emile

PS. Une méthode didactique pour comprendre le RSA est d'effectuer une
simulation avec des petits nombres. Par exemple, p, q, N7 (*17),
on adopte e=7, on calcule d#, soit le message M, le message chiffré.
Tous ces calculs peuvent facilement s'effectuer à la main.
Pourrait-on faire une telle simulation avec votre cryptage pyramidale en
utilisant des petits nombres?

Klopfenstein Michaël

23/11/2003 à 17:38

En plus il doit y avoir une erreur d'indice dans la notation A indice 1,i
car en developpant on voit que i varie de 1 a k et non de 1 a 2 puissance
k

Quelles ligne je n'ai pas trouvé? Dans A indice i,j on a
- j varie de 1 à k
- et pour j=1 on a que i varie de 1 à 2^(k-1) donc les indices 2i et 2i-1
varient de 1 à 2^k
- pour j quelconque i varie de 1 à 2^(k-j) donc les indice 2i et 2i-1 varie
de 1 à 2^(k-j+1)

D'autre part il y a des indices de ce B. Schneier appelle du "snake oil",
en

particulier le fait de creer des appellations "maison" pour des concepts
deja existants en cryptologie.

Je suis désolé ce que j'ai nomé personnellement c'est parce que je ne le
connaissait pas à ce moment là.

la taille d'un systeme a resoudre n'est pas forcement un obstacle dirimant
lors d'un decryptement, contrairement a ce que vous affirmez.
L'inversion d'une matrice est d'une complexité polynomiale (au cube je

crois), de sorte que la taille n'est pas vraiment un problème, à moins que
cette taille soit..énorme : je ne pense pas qu'il soit possible de résoudre
une matrice de 10^30 termes de côté... C'est à ce type de taille qu'aboutit
une résolution linéaire du cryptage.
Dans l'autre cas de figure, il faut résoudre un système non linéaire
diophantien sur Fp (du 2ème degré ou plus) et dans ce cas, il me semble que
la taille (le nombres de variables) rend nettement le problème plus
difficiles.

Bref je ne dis que le systeme est mauvais, je ne dis pas qu'il est bon,
mais

j'affirme qu'en presentant les choses plus clairement, plus completement,
ca ferait gagner du temps a tout le monde.
J'ai essayé dans donner la forme la plus condensé.

Proposition : cryptage pyramidale

10 réponses

Veuillez sélectionner un problème