Cryptage pyramidal
Le
Klopfenstein Michaël
Suite aux remarques que vous m'avez faites, j'ai pris un peu de temps pour :
- faire un document d'accompagnement afin de détailler le mécanisme
du cryptage pyramidal (désolé il reste encore assez compliqué, il faudrait
un temps immense pour détailler un exemple complet, j'espère qu'il peut
néanmoins être utile). Vous le trouverez sur mon site à côté de l'article
http://www.pyramidal.fr.vu
Peut-être certains pourront-il apporter une critique plus précise avec cette
petite aide supplémentaire.
- Retoucher légèrement le programme (qu'on peut télécharger à la même
adresse).
Sur les remarques faites :
**On m'a fait une remarque sur la vitesse :
Avec cette petite retouche le programme tourne 50 à 60 fois plus vite que le
dernier.
Il est très probable qu'on puisse encore un peu améliorer cela avec plus de
réflexion.
(5s pour le cryptage d'un fichier de 1,3Mo avec un processeur de 1.5GHz)
Selon les mesures de Pierre Vandevenne, cela le ramène à 70 fois plus lent
qu'AES (acrypt??)
ou 250 fois lent qu'un AES optimisé, basé sur son estimation.
Sachant que c'est un logiciel de cryptage asymétrique est-ce que ce n'est
pas une bonne performance? (Je ne connais pas les comparaisons RSA - AES)
Comme défaut par contre, il demande sans doute plus de mémoire que RSA (sans
reflexion : j'imagine 1 ou 2 Mo pour p n2)
**On m'a fait une remarque sur le doublement de la taille (et même un peu
plus)
Cela par principe je ne peux le réduire à moins du double, mais en
fonctionnement mixte avec un logiciel de cryptage standard n'est-ce pas plus
ou moins négligeable?
**On m'a fait la remarque que l'article parlait de p1 et le logiciel p.
J'ai expliquer que cela changeait seulement un peu le niveau de sécurité et
les temps de calculs.
Il se trouve qu'avec les modifications apporter aux logiciels, j'ai été
surpis de constater qu'il tourne à très peu de chose près aussi vite avec
p1, seul le calcul des clés est beaucoup plus long.
**On m'a fait une remarque sur l'apparition d'une répétition en cryptant
beaucoup d'espaces.
j'en ai déjà expliqué la raison (codage par codon fixe).
J'ai modifié le logiciel, en introduisant le résultat du cryptage dans
chaque codon suivant, ce qui devrait faire disparaitre ce phénomène et
rendre le logiciel utilisable pour un cryptage plus standard.
MK
- faire un document d'accompagnement afin de détailler le mécanisme
du cryptage pyramidal (désolé il reste encore assez compliqué, il faudrait
un temps immense pour détailler un exemple complet, j'espère qu'il peut
néanmoins être utile). Vous le trouverez sur mon site à côté de l'article
http://www.pyramidal.fr.vu
Peut-être certains pourront-il apporter une critique plus précise avec cette
petite aide supplémentaire.
- Retoucher légèrement le programme (qu'on peut télécharger à la même
adresse).
Sur les remarques faites :
**On m'a fait une remarque sur la vitesse :
Avec cette petite retouche le programme tourne 50 à 60 fois plus vite que le
dernier.
Il est très probable qu'on puisse encore un peu améliorer cela avec plus de
réflexion.
(5s pour le cryptage d'un fichier de 1,3Mo avec un processeur de 1.5GHz)
Selon les mesures de Pierre Vandevenne, cela le ramène à 70 fois plus lent
qu'AES (acrypt??)
ou 250 fois lent qu'un AES optimisé, basé sur son estimation.
Sachant que c'est un logiciel de cryptage asymétrique est-ce que ce n'est
pas une bonne performance? (Je ne connais pas les comparaisons RSA - AES)
Comme défaut par contre, il demande sans doute plus de mémoire que RSA (sans
reflexion : j'imagine 1 ou 2 Mo pour p n2)
**On m'a fait une remarque sur le doublement de la taille (et même un peu
plus)
Cela par principe je ne peux le réduire à moins du double, mais en
fonctionnement mixte avec un logiciel de cryptage standard n'est-ce pas plus
ou moins négligeable?
**On m'a fait la remarque que l'article parlait de p1 et le logiciel p.
J'ai expliquer que cela changeait seulement un peu le niveau de sécurité et
les temps de calculs.
Il se trouve qu'avec les modifications apporter aux logiciels, j'ai été
surpis de constater qu'il tourne à très peu de chose près aussi vite avec
p1, seul le calcul des clés est beaucoup plus long.
**On m'a fait une remarque sur l'apparition d'une répétition en cryptant
beaucoup d'espaces.
j'en ai déjà expliqué la raison (codage par codon fixe).
J'ai modifié le logiciel, en introduisant le résultat du cryptage dans
chaque codon suivant, ce qui devrait faire disparaitre ce phénomène et
rendre le logiciel utilisable pour un cryptage plus standard.
MK
Poser une question
algorithmes RSA et AES pour une même puissance de calcul (même taille de
clé, disons 128 bits) ?
(évidemment RSA seul, pas en mode mixte avec un cryptage symétrique)
Il n'y a pas grand monde qui s'amuse à tester cela car c'est totalement
inutile.
Là, j'aurais tendance à vous resservir (sans méchanceté, et avec un
petit clin d'oeil), l'avertissement que vous placez sur votre page à
l'usage des non-mathématiciens: si vous ne savez pas comment les
ordinateurs fonctionnent, comment ils représentent les nombres, comment
ils les manipulent, ne risquez pas de questions comme celle là
Regardons par exemple ceci
http://www.eskimo.com/~weidai/benchmarks.html
et remarquons que rijndael/AES 256 bits, toutes autres choses étant
égales n'est pas deux fois plus lent que rijndael/AES 128 bits, loin,
très loin de là et qu'une signature RSA-1024 est, toutes autres choses
étant égales, 5 à 6 fois plus rapide qu'une signature RSA-2048.
On peut en tirer beaucoup de conclusions et principalement que la
comparaison, en plus d'être sans objet, est presque impossible.
La vitesse va en outre dépendre de l'implémentation (dont la philosophie
va dépendre elle-même de contraintes éventuelles de mémoire ou de
puissance processeur), de la taille des mots manipulés par la processeur
en cause, de son architecture mémoire, de sa cache éventuelle, du type
d'algorithme symétrique ou asymétrique, de la nature des nombres
manipulés, etc... etc... (liste non exhaustive et de très loin à cette
heure).
Donc, non seulement on compare la surface d'une pomme au volume d'une
poire, mais en plus on le fait sur des planètes différentes dans un
système solaire différent.
Si la crypto est un sous-domaine intéressant des maths pures, il ne faut
pas oublier quelques faits essentiels
1) on connait le système idéal et parfait pour tout: le One Time Pad.
Malheureusement, il est très très contraignant.
2) compte tenu de 1, on s'applique à inventer des systèmes craquables en
un temps fini et défini que l'on espère très grand qui minimisent les
contraintes pratiques pour les applications que l'on a en tête (une
carte n'est pas ASCI Blue. La contrainte pratique et l'économie de moyen
dans le cadre de cette contrainte sont les raisons d'être de la
cryptographie moderne.
C'est pour cette raison que les chercheurs d'IBM essaient de faire de
leur mieux avec 7 ou 8 octets(*) quand ils inventent le DES. C'est pour
cette raison que Diffie et Hellman inventent le protocole qui porte leur
nom au lieu de suggérer une immense base de données qui contiendrait un
couple de clés symétriques pour chaque paire d'être humain passée et à
venir et chaque transaction qu'ils pourraient envisager.
C'est aussi pour cette raison que les nouveaux protocoles sont regardés
avec peu d'intérêt quand ils négligent d'emblée les contraintes du
moment.
Il me semble qu'il est notoire que RSA est plus lent que AES, et j'imagine
qu'il existe un cadre pour estimer cela. Je sais que toute mesure sera
dépendante du cadre dans lequel on l'a faite, que certains cadres de mise en
oeuvre seront plus propices à l'une ou l'autre des méthodes, voire
incompatible. Mais je pensque qu'il existe malgré cela un moyen de se faire
une idée (forcément un peu subjective) en terme de quantité de calcul
nécessaire.
En mathématique, on possède la notion réduction polynomiale et de complexité
d'un algorithme qui donne une sorte de majoration du nombre de calcul à
faire pour ramener le problème
à un algorithme simplifier (en général des test bruts). Le résultat se donne
souvent en degré
polynomial ; on dit que tel problème est polynomial de tel degré, ce qui
permet d'apprécier
(subjectivement) sa vitesse de résolution. De nombreux chercheurs et thesard
s'évertue sans cesse calculer la complexité de certains problèmes, il serait
étrangement surprenant que ce travail n'ait pas été fait pour RSA et AES. Si
le résultat n'est jamais source de fiabilité est de certitude (un théorème
dit que la complexité d'un problème n'est pas calculable, seulement
majorable), il est quand même un indice de réalité important.
Vu ces théorèmes et cette pratique mathématique, il me semble assez naturel
de vouloir comparer deux algorithmes de cryptage quelconque qui parte d'un
même texte et qui arrive les deux à un texte crypté. Une méthode (et c'est
là peut-être que je suis naïf) simple consisterait à faire tourner deux
algorithmes optimisés sur une grande quantité de donnés dans des 'conditions
à peu près similaire' . Et pour ces conditions, libre cours à une définition
qui essaie de donner un semblant de réalité. Si je posais maladroitement une
limite à 128 bits c'est pour avoir une sorte d'homogénéité (sachant bien
qu'un bit pour RSA demande beaucoup plus de calcul à craquer qu'un bit pour
AES), mais il faut apporter une certaine similarité, arbitraire certes.
Comparer la surface d'une pomme au volume d'une poire dans des conditions
envisageables de
différentiabilité de la surface et de compacité bien définie, peut-être un
indice très intéressant de la comparaison des volumes ou des surfaces
(puisqu'elles sont liées) ;-)
MK
Certainement, et c'est pour cela qu'on ne compare pas directement RSA et
AES.
RSA, faudra-t-il vous le répétez combien de fois ?, ne s'utilise
*jamais* dans les mêmes conditions que AES, *jamais* pour chiffrer un
même texte, dans les protocoles de cryptographie utilisés dans le public.
"Klopfenstein Michaël"