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=17 n=32)
**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 p=31 et le logiciel p=17.
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
p=31, 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.
Quelqu'un connaitrait-il les comparatifs de débit de cryptage entre les 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)
Quelqu'un connaitrait-il les comparatifs de débit de cryptage entre les
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)
Quelqu'un connaitrait-il les comparatifs de débit de cryptage entre les 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)
Pierre Vandevenne
"Klopfenstein Michaël" wrote in news:bqogqk$eo6$:
Quelqu'un connaitrait-il les comparatifs de débit de cryptage entre les
algorithmes RSA et AES pour une même puissance de calcul
Il n'y a pas grand monde qui s'amuse à tester cela car c'est totalement inutile.
(même taille de clé, disons 128 bits) ?
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.
"Klopfenstein Michaël" <m.klofpenstein@libertysurf.fr> wrote in
news:bqogqk$eo6$1@news.tiscali.fr:
Quelqu'un connaitrait-il les comparatifs de débit de cryptage entre
les
algorithmes RSA et AES pour une même puissance de calcul
Il n'y a pas grand monde qui s'amuse à tester cela car c'est totalement
inutile.
(même taille de clé, disons 128 bits) ?
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.
Quelqu'un connaitrait-il les comparatifs de débit de cryptage entre les
algorithmes RSA et AES pour une même puissance de calcul
Il n'y a pas grand monde qui s'amuse à tester cela car c'est totalement inutile.
(même taille de clé, disons 128 bits) ?
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.
Klopfenstein Michaël
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.
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
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.
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) ;-)
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.
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
Jean-Marc Desperrier
Klopfenstein Michaël wrote:
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é.
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 wrote:
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é.
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.
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é.
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" wrote in message news:<bqogqk$eo6$...
Quelqu'un connaitrait-il les comparatifs de débit de cryptage entre les 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)
"Klopfenstein Michaël" <m.klofpenstein@libertysurf.fr> wrote in message news:<bqogqk$eo6$1@news.tiscali.fr>...
Quelqu'un connaitrait-il les comparatifs de débit de cryptage entre les
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)
"Klopfenstein Michaël" wrote in message news:<bqogqk$eo6$...
Quelqu'un connaitrait-il les comparatifs de débit de cryptage entre les 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)
Erwann ABALEA
Bonjour,
On Fri, 5 Dec 2003, Klopfenstein Michaël wrote:
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
Oui, comme il est notoire qu'une moto peut être plus rapide qu'un camion, mais est-ce utile de comparer leurs vitesses si le but final est de savoir en combien de temps on pourra transporter un container d'un endroit à un autre?
En RSA, typiquement, vous ne chiffrerez qu'une clé de session, et cette clé de session sera utilisée avec l'AES pour chiffrer les données (pour prendre la même analogie, avec la moto vous allez de chez vous à votre entrepot, et vous empruntez ensuite un camion pour faire le boulot).
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.
Ca n'est pas homogène du tout, puisque 128 bits de RSA ne 'valent' pas 128 bits d'AES en terme de sécurité. Une clé RSA 128 bits se casse en quelques secondes, une clé AES 128 bits prend très nettement plus de temps.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- FC> Commencez par ne pas envoyer vos contributions en triple exemplaire JD> Quelle contribution ? J'abandonne. PLONK. -+- FC in GNU : Une fois, 2 fois, 3 fois, adjugé au plonké du fond -+-
Bonjour,
On Fri, 5 Dec 2003, Klopfenstein Michaël wrote:
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
Oui, comme il est notoire qu'une moto peut être plus rapide qu'un camion,
mais est-ce utile de comparer leurs vitesses si le but final est de savoir
en combien de temps on pourra transporter un container d'un endroit à un
autre?
En RSA, typiquement, vous ne chiffrerez qu'une clé de session, et cette
clé de session sera utilisée avec l'AES pour chiffrer les données (pour
prendre la même analogie, avec la moto vous allez de chez vous à votre
entrepot, et vous empruntez ensuite un camion pour faire le boulot).
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.
Ca n'est pas homogène du tout, puisque 128 bits de RSA ne 'valent' pas 128
bits d'AES en terme de sécurité. Une clé RSA 128 bits se casse en quelques
secondes, une clé AES 128 bits prend très nettement plus de temps.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
FC> Commencez par ne pas envoyer vos contributions en triple exemplaire
JD> Quelle contribution ?
J'abandonne. PLONK.
-+- FC in GNU : Une fois, 2 fois, 3 fois, adjugé au plonké du fond -+-
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
Oui, comme il est notoire qu'une moto peut être plus rapide qu'un camion, mais est-ce utile de comparer leurs vitesses si le but final est de savoir en combien de temps on pourra transporter un container d'un endroit à un autre?
En RSA, typiquement, vous ne chiffrerez qu'une clé de session, et cette clé de session sera utilisée avec l'AES pour chiffrer les données (pour prendre la même analogie, avec la moto vous allez de chez vous à votre entrepot, et vous empruntez ensuite un camion pour faire le boulot).
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.
Ca n'est pas homogène du tout, puisque 128 bits de RSA ne 'valent' pas 128 bits d'AES en terme de sécurité. Une clé RSA 128 bits se casse en quelques secondes, une clé AES 128 bits prend très nettement plus de temps.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- FC> Commencez par ne pas envoyer vos contributions en triple exemplaire JD> Quelle contribution ? J'abandonne. PLONK. -+- FC in GNU : Une fois, 2 fois, 3 fois, adjugé au plonké du fond -+-
Klopfenstein Michaël
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.
<Protocole public:> Mais pourquoi est-ce que RSA ne s'utilise pas comme cryptage complet dans les protocole public ? Il m'a sembé comprendre que c'est à cause de sa lenteur, qu'est-ce qui l'empécherait de l'utiliser de façon continue. Si l'inconvénient est bien sa lenteur j'imagine qu'il y a moyen de dire celui là est lent celui là est plus rapide. Et donc qu'il existe des moyens de donner une certaine idée de la différence.
<mêmes conditions > Même si l'usage de chaque procédé repose sur des conditions d'usage complètement différent et donc une analyse forcément subjective.J'imagine qu'on peut donc s'apercevoir que RSA est réellement plus lent qu'AES, et donc par quelques chiffres qui établisse toute sorte de point de comparaison possible dans des conditions différente, on puisse se faire finalement une idée de la vitesse comparée de chacune des méthode. (Une vision précise incluera naturellement les conditionnements qui favorise tel ou telle méthode). Ce n'est pas parce qu'on fait jamais quelque chose qu'on ne peut pas s'interroger sur *pourquoi on le fait jamais*, et il me semble que c'est une question de *vitesse qui est la base*, est-ce que je me trompe? Si c'est le cas il y a sans doute un moyen de donner une idée de comparaison, non? Ou-est ce que je me trompe? A moins que je n'ai pas le droit de m'interesser à 'quelle vitesse crypterait RSA, si on cryptait uniquement avec lui', puisque cela ne se fait pas?
En résumé, puisqu'on m'a fourni des données pour AES (merci à 'salus') quelqu'un connaitrait-il des éléments de vitesse de cryptement par RSA, (je me chargerai seul d'en estimer toute la subjectivité. En me trompant certainement, car je ne connais pas toute la subtilité de la sécurité des algorithmes mais tant pis pour moi. La connaissance progresse toujours par approximation et simplification)
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.
<Protocole public:>
Mais pourquoi est-ce que RSA ne s'utilise pas comme cryptage complet dans
les protocole public ? Il m'a sembé comprendre que c'est à cause de sa
lenteur, qu'est-ce qui l'empécherait de l'utiliser de façon continue.
Si l'inconvénient est bien sa lenteur j'imagine qu'il y a moyen de dire
celui là est lent celui là est plus rapide. Et donc qu'il existe des moyens
de donner une certaine idée de la différence.
<mêmes conditions >
Même si l'usage de chaque procédé repose sur des conditions d'usage
complètement différent
et donc une analyse forcément subjective.J'imagine qu'on peut donc
s'apercevoir que RSA est réellement plus lent qu'AES, et donc par quelques
chiffres qui établisse toute sorte de point de
comparaison possible dans des conditions différente, on puisse se faire
finalement une idée de la vitesse comparée de chacune des méthode. (Une
vision précise incluera naturellement les conditionnements qui favorise tel
ou telle méthode).
Ce n'est pas parce qu'on fait jamais quelque chose qu'on ne peut pas
s'interroger sur
*pourquoi on le fait jamais*, et il me semble que c'est une question de
*vitesse qui est la base*, est-ce que je me trompe?
Si c'est le cas il y a sans doute un moyen de donner une idée de
comparaison, non?
Ou-est ce que je me trompe? A moins que je n'ai pas le droit de m'interesser
à 'quelle vitesse crypterait RSA, si on cryptait uniquement avec lui',
puisque cela ne se fait pas?
En résumé, puisqu'on m'a fourni des données pour AES (merci à 'salus')
quelqu'un connaitrait-il des éléments de vitesse de cryptement par RSA, (je
me chargerai seul d'en estimer toute la subjectivité. En me trompant
certainement, car je ne connais pas toute la subtilité de la sécurité des
algorithmes mais tant pis pour moi. La connaissance progresse toujours par
approximation et simplification)
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.
<Protocole public:> Mais pourquoi est-ce que RSA ne s'utilise pas comme cryptage complet dans les protocole public ? Il m'a sembé comprendre que c'est à cause de sa lenteur, qu'est-ce qui l'empécherait de l'utiliser de façon continue. Si l'inconvénient est bien sa lenteur j'imagine qu'il y a moyen de dire celui là est lent celui là est plus rapide. Et donc qu'il existe des moyens de donner une certaine idée de la différence.
<mêmes conditions > Même si l'usage de chaque procédé repose sur des conditions d'usage complètement différent et donc une analyse forcément subjective.J'imagine qu'on peut donc s'apercevoir que RSA est réellement plus lent qu'AES, et donc par quelques chiffres qui établisse toute sorte de point de comparaison possible dans des conditions différente, on puisse se faire finalement une idée de la vitesse comparée de chacune des méthode. (Une vision précise incluera naturellement les conditionnements qui favorise tel ou telle méthode). Ce n'est pas parce qu'on fait jamais quelque chose qu'on ne peut pas s'interroger sur *pourquoi on le fait jamais*, et il me semble que c'est une question de *vitesse qui est la base*, est-ce que je me trompe? Si c'est le cas il y a sans doute un moyen de donner une idée de comparaison, non? Ou-est ce que je me trompe? A moins que je n'ai pas le droit de m'interesser à 'quelle vitesse crypterait RSA, si on cryptait uniquement avec lui', puisque cela ne se fait pas?
En résumé, puisqu'on m'a fourni des données pour AES (merci à 'salus') quelqu'un connaitrait-il des éléments de vitesse de cryptement par RSA, (je me chargerai seul d'en estimer toute la subjectivité. En me trompant certainement, car je ne connais pas toute la subtilité de la sécurité des algorithmes mais tant pis pour moi. La connaissance progresse toujours par approximation et simplification)
Klopfenstein Michaël
Oui, comme il est notoire qu'une moto peut être plus rapide qu'un camion, mais est-ce utile de comparer leurs vitesses si le but final est de savoir en combien de temps on pourra transporter un container d'un endroit à un autre?
Et si ma question était "pourquoi ne fait-on pas de véhicule hybride, les moto-camions?" est-il insensé de la posé?
Ce n'est pas parce qu'une méthode asymétrique ne fait que transporter une clé, qu'il est interdit de s'interroger sur : et si l'on parvenait à faire une méthode asymétrique plus rapide qu'une méthode symétrique, n'y aurait-il pas intérêt à utiliser uniquement la cryptage asymétrique (par exemple pour crypter des flux de donnée, cela présenterait un réel avantage : pas besoin d'envoyer sans cesse une nouvelle clé). Si c'est le cas il devient réellement très utile d'avori une petite idée de comparé RSA et AES. Mais évidemment, il me semble avoir compris que ce n'est pas le cas, il me semble que RSA est plus lent, est-ce faux ?
Oui, comme il est notoire qu'une moto peut être plus rapide qu'un camion,
mais est-ce utile de comparer leurs vitesses si le but final est de savoir
en combien de temps on pourra transporter un container d'un endroit à un
autre?
Et si ma question était "pourquoi ne fait-on pas de véhicule hybride, les
moto-camions?"
est-il insensé de la posé?
Ce n'est pas parce qu'une méthode asymétrique ne fait que transporter une
clé, qu'il est interdit
de s'interroger sur : et si l'on parvenait à faire une méthode asymétrique
plus rapide qu'une méthode symétrique, n'y aurait-il pas intérêt à utiliser
uniquement la cryptage asymétrique (par exemple pour crypter des flux de
donnée, cela présenterait un réel avantage : pas besoin d'envoyer sans cesse
une nouvelle clé). Si c'est le cas il devient réellement très utile d'avori
une petite idée de comparé RSA et AES. Mais évidemment, il me semble avoir
compris que ce n'est pas le cas, il me semble que RSA est plus lent, est-ce
faux ?
Oui, comme il est notoire qu'une moto peut être plus rapide qu'un camion, mais est-ce utile de comparer leurs vitesses si le but final est de savoir en combien de temps on pourra transporter un container d'un endroit à un autre?
Et si ma question était "pourquoi ne fait-on pas de véhicule hybride, les moto-camions?" est-il insensé de la posé?
Ce n'est pas parce qu'une méthode asymétrique ne fait que transporter une clé, qu'il est interdit de s'interroger sur : et si l'on parvenait à faire une méthode asymétrique plus rapide qu'une méthode symétrique, n'y aurait-il pas intérêt à utiliser uniquement la cryptage asymétrique (par exemple pour crypter des flux de donnée, cela présenterait un réel avantage : pas besoin d'envoyer sans cesse une nouvelle clé). Si c'est le cas il devient réellement très utile d'avori une petite idée de comparé RSA et AES. Mais évidemment, il me semble avoir compris que ce n'est pas le cas, il me semble que RSA est plus lent, est-ce faux ?
Klopfenstein Michaël
L'intention de ma demande est de savoir ''de combien les systèmes asymétriques sont trop lents'' pour concurencer les systèmes symétriques dans le cryptage en continu. Cette question ne possède-t-elle pas une réponse ? Forcément nuancer vu les difficultés de comparaison, mais entre nuancer et impossible il y a une mesure. Est-ce que je me trompe quelque part ?
L'intention de ma demande est de savoir ''de combien les systèmes
asymétriques sont trop lents'' pour concurencer les systèmes symétriques
dans le cryptage en continu.
Cette question ne possède-t-elle pas une réponse ?
Forcément nuancer vu les difficultés de comparaison, mais entre nuancer et
impossible il y a une mesure.
Est-ce que je me trompe quelque part ?
L'intention de ma demande est de savoir ''de combien les systèmes asymétriques sont trop lents'' pour concurencer les systèmes symétriques dans le cryptage en continu. Cette question ne possède-t-elle pas une réponse ? Forcément nuancer vu les difficultés de comparaison, mais entre nuancer et impossible il y a une mesure. Est-ce que je me trompe quelque part ?
Jean-Marc Desperrier
Klopfenstein Michaël wrote:
Et si ma question était "pourquoi ne fait-on pas de véhicule hybride, les moto-camions?" est-il insensé de la posé?
Le système actuel est hybride.
de s'interroger sur : et si l'on parvenait à faire une méthode asymétrique plus rapide qu'une méthode symétrique,
C'est bien, mais elle devra battre les autres méthodes sur deux terrains simultanément, les mots en vitesse et les camions en capacité de transport. Ca parait un sacré défi.
[...] (par exemple pour crypter des flux de donnée, cela présenterait un réel avantage : pas besoin d'envoyer sans cesse une nouvelle clé).
Bof, l'envoie de la nouvelle clé est intégré aux données de gestion, et on aura toujours en pratique des données de gestion à envoyer dans les flux, donc ce n'est pas vraiment une gène en pratique.
Si c'est le cas il devient réellement très utile d'avori une petite idée de comparé RSA et AES.
Ah ben non. Il sera utile de comparer la vitesse de chifrement de votre super méthode pour montrer qu'elle est plus rapide que AES en chiffrement, tout en ayant bien les propriétés utiles et la même sécurité que les autres méthode assymétriques.
Bon, en réalité, dans la méthode hybride qu'on utilise aujourd'hui, le temps total est le temps passé pour chiffrer avec AES + le temps pour chiffrer la clé de session avec RSA, et si votre méthode assymétrique bat cela pour un niveau de sécurité équivalent, elle commence à être intéressante.
Mais le problème est de définir la taille du bloc de donnée, et que assymptotiquement quand le bloc est grand, le temps de chiffrement de la clé de session devient négligeable, on en revient à battre AES en vitesse, ce qui est dur, dur pour de l'assymétrique.
Si on pouvait dire que les blocs de plus de 500ko sont rares, et que vous battez encore le couple AES/RSA pour ce cas, ça peut être intéressant.
Mais est-ce bien vrai ? Dans une session SSL on est capable d'échanger des mega de données avant de changer de clé, et si on est perdant dans ce cas, la méthode perd nettement de son intérêt. Et si cela se trouve en fait, les deux opérations sont réalisées par les systèmes actuels suffisament vite, pour que ce ne soit pas un critère très déterminant pour donner envie de changer de système.
Klopfenstein Michaël wrote:
Et si ma question était "pourquoi ne fait-on pas de véhicule hybride, les
moto-camions?"
est-il insensé de la posé?
Le système actuel est hybride.
de s'interroger sur : et si l'on parvenait à faire une méthode asymétrique
plus rapide qu'une méthode symétrique,
C'est bien, mais elle devra battre les autres méthodes sur deux terrains
simultanément, les mots en vitesse et les camions en capacité de
transport. Ca parait un sacré défi.
[...] (par exemple pour crypter des flux de
donnée, cela présenterait un réel avantage : pas besoin d'envoyer sans cesse
une nouvelle clé).
Bof, l'envoie de la nouvelle clé est intégré aux données de gestion, et
on aura toujours en pratique des données de gestion à envoyer dans les
flux, donc ce n'est pas vraiment une gène en pratique.
Si c'est le cas il devient réellement très utile d'avori
une petite idée de comparé RSA et AES.
Ah ben non. Il sera utile de comparer la vitesse de chifrement de votre
super méthode pour montrer qu'elle est plus rapide que AES en
chiffrement, tout en ayant bien les propriétés utiles et la même
sécurité que les autres méthode assymétriques.
Bon, en réalité, dans la méthode hybride qu'on utilise aujourd'hui, le
temps total est le temps passé pour chiffrer avec AES + le temps pour
chiffrer la clé de session avec RSA, et si votre méthode assymétrique
bat cela pour un niveau de sécurité équivalent, elle commence à être
intéressante.
Mais le problème est de définir la taille du bloc de donnée, et que
assymptotiquement quand le bloc est grand, le temps de chiffrement de la
clé de session devient négligeable, on en revient à battre AES en
vitesse, ce qui est dur, dur pour de l'assymétrique.
Si on pouvait dire que les blocs de plus de 500ko sont rares, et que
vous battez encore le couple AES/RSA pour ce cas, ça peut être intéressant.
Mais est-ce bien vrai ? Dans une session SSL on est capable d'échanger
des mega de données avant de changer de clé, et si on est perdant dans
ce cas, la méthode perd nettement de son intérêt.
Et si cela se trouve en fait, les deux opérations sont réalisées par les
systèmes actuels suffisament vite, pour que ce ne soit pas un critère
très déterminant pour donner envie de changer de système.
Et si ma question était "pourquoi ne fait-on pas de véhicule hybride, les moto-camions?" est-il insensé de la posé?
Le système actuel est hybride.
de s'interroger sur : et si l'on parvenait à faire une méthode asymétrique plus rapide qu'une méthode symétrique,
C'est bien, mais elle devra battre les autres méthodes sur deux terrains simultanément, les mots en vitesse et les camions en capacité de transport. Ca parait un sacré défi.
[...] (par exemple pour crypter des flux de donnée, cela présenterait un réel avantage : pas besoin d'envoyer sans cesse une nouvelle clé).
Bof, l'envoie de la nouvelle clé est intégré aux données de gestion, et on aura toujours en pratique des données de gestion à envoyer dans les flux, donc ce n'est pas vraiment une gène en pratique.
Si c'est le cas il devient réellement très utile d'avori une petite idée de comparé RSA et AES.
Ah ben non. Il sera utile de comparer la vitesse de chifrement de votre super méthode pour montrer qu'elle est plus rapide que AES en chiffrement, tout en ayant bien les propriétés utiles et la même sécurité que les autres méthode assymétriques.
Bon, en réalité, dans la méthode hybride qu'on utilise aujourd'hui, le temps total est le temps passé pour chiffrer avec AES + le temps pour chiffrer la clé de session avec RSA, et si votre méthode assymétrique bat cela pour un niveau de sécurité équivalent, elle commence à être intéressante.
Mais le problème est de définir la taille du bloc de donnée, et que assymptotiquement quand le bloc est grand, le temps de chiffrement de la clé de session devient négligeable, on en revient à battre AES en vitesse, ce qui est dur, dur pour de l'assymétrique.
Si on pouvait dire que les blocs de plus de 500ko sont rares, et que vous battez encore le couple AES/RSA pour ce cas, ça peut être intéressant.
Mais est-ce bien vrai ? Dans une session SSL on est capable d'échanger des mega de données avant de changer de clé, et si on est perdant dans ce cas, la méthode perd nettement de son intérêt. Et si cela se trouve en fait, les deux opérations sont réalisées par les systèmes actuels suffisament vite, pour que ce ne soit pas un critère très déterminant pour donner envie de changer de système.
