temps d'exécution du AES et du RSA
Le
kabina
Bonjour,
j'ai calculé les différents temps d'exécution des algorithmes AES et RSA et voici ce que j'ai obtenu:
AES 128 bits de clé, 2,58 Mo de fichier à chiffrer avec un temps de 203 ms
AES 128 bits de clé, 9,16 Mo de fichier à chiffrer avec un temps de 500 ms et RAM utilisé 21695k
RSA 2048 bits de clé, 2,58 Mo de fichier à chiffrer avec un temps de 21621 ms et RAM 8590 k
RSA 2048 bits de clé, 9,16 Mo de fichier à chiffrer avec un temps de 74583 ms et RAM 22665 k
notez que je calcule juste le temps de l'opération de chiffrement et pas les entrées/sorties(lecture du fichier à chiffré et enregistrement du fichier chiffré) ni la récupération des certificat .cer et .p12 (clé publique et clé privée)
A votre avis est ce que c'est cohérent !!!!
merci à vous et bonne soirée.
j'ai calculé les différents temps d'exécution des algorithmes AES et RSA et voici ce que j'ai obtenu:
AES 128 bits de clé, 2,58 Mo de fichier à chiffrer avec un temps de 203 ms
AES 128 bits de clé, 9,16 Mo de fichier à chiffrer avec un temps de 500 ms et RAM utilisé 21695k
RSA 2048 bits de clé, 2,58 Mo de fichier à chiffrer avec un temps de 21621 ms et RAM 8590 k
RSA 2048 bits de clé, 9,16 Mo de fichier à chiffrer avec un temps de 74583 ms et RAM 22665 k
notez que je calcule juste le temps de l'opération de chiffrement et pas les entrées/sorties(lecture du fichier à chiffré et enregistrement du fichier chiffré) ni la récupération des certificat .cer et .p12 (clé publique et clé privée)
A votre avis est ce que c'est cohérent !!!!
merci à vous et bonne soirée.
ça va dépendre de l'implémentation, de la machine, du chainage, et dans
le cas de RSA de l'algorithme de chiffrement à clef secrète utilisé (on
ne chifre JAMAIS plusieurs méga octets en RSA).
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
oui je sais que le mieux c'est d'utiliser un chiffrement hybride.
Ce que je suis entrain de faire est dans le cadre d'un projet ou je dois vérifier par moi même les vitesses d'exécution (illustrer la lenteur du RSA).
machine
Processor : Intel(R) Core(TM) 2 CPU T5200 1,6GHZ.
Ram : 1,00 Go.
Mode ECB (RSA)
a+
21.2 Mo pour traiter 9.16 Mo signifie sûrement que vous stockez
le résultat dans un buffer différent de celui d'entrée, c'est souvent
non requis, le chiffrement étant réalisé "en place" de plus si l'on
traite d'un flux, un tampon (de 128, 256+ Ko) est suffisant pour faire
le traitement à la volée, lire l'intégralité du flux d'entrant avant
de le traiter (et donc allouer un buffer de sa taille) est également
généralement inutile.
vos "conclusions" sont la mémoire requise sont de fait non pertinentes.
concernant les performances brutes d'un AES 128 bits, elles peuvent
varier d'une implémentation à une autre et de l'architecture du CPU,
vous n'indiquez pas l'implémentation; bien noté l'usage d'un T5200
(1,6GHZ, FSB 533MHz, L2 2Mo) qui est CPU "bas de gamme" pour portable.
avec un CPU "de desktop" (E8400), une implémentation C compilée par
MS cl 14, 10Mo sont traités en moins de 200ms (à 2GHz, le CPU n'a pas
le temps de switcher à 3GHz) - 5 à 50ms par mégaoctet sont des
chiffres ordinaires.
cela n'a aucun sens !
que veux dire ici "temps d'exécution de l'algorithme RSA" ??
vous appliquez un /chiffrement/ et donc une exponentiation avec 2
ou 3 bits (de l'exponent publique) ou un /déchiffrement/ et donc
une exponentiation avec (de l'ordre de) 1024 bits (+/- 1024) ?
sur les 10 Mo d'entrée vous traitez combien d'octets à la fois ?
cela ne peux pas être 256 sous peine de risquer d'avoir des nombres
supérieurs au modulus de la clé, donc combien ? 255, 245 ?...
(avec un exposant publique de 0x010001, je traite 10Mo pris par
paquet de 255 octets en 17 sec.).
pareil.
c'est surtout dénué de sens !!
si on vous a demandé de "vérifier par vous même la lenteur du RSA",
on ne vous a sûrement pas demander de vérifier qu'un chiffrement RSA
est débile, ou alors vous pouvez dire à ce demandeur qu'il est débile.
un algo symétrique a des contraintes, dont performance intrinsèque,
temps constant (!!), facilité d'implémentation hard, ...
un algo asymétrique a aussi des contraintes mais elles sont tout à
fait différentes, résistance de la clé privée, facilité de publication
de la clé publique (génération et taille des certs), ...
si le but de cet exercice est de "montrer" qu'il vaut mieux chiffrer
en AES qu'en RSA, c'est une insulte au bon sens et à la compréhension
élémentaire de la crypto.
Sylvain.
tout d'abord je vous remercie de votre aide.
Je ne vois pas à quel moment j'ai dis que le but de l'exercice est de monter qu'il vaut mieux chiffrer en AES qu'en RSA !!!!!!!!!!!
Je sais bien que chaque algorithme a des avantages et des inconvénients!!!!! et tout dépend de ce que on veut en faire. c'est élémentaire.
Peut être que je me suis mal exprimé!! quand je dis comparaison c'est pas dans le sens qui est mieux que qui!!!! et c'est dénué de sens d'interpréter les choses de la sorte!!! c'est comparaison en terme de rapidité de chiffrement. Et a ce que je sache RSA est plus lent, je répète plus lent pas moins bon ou plus bon (pas de jugement subjectif) que le AES.
Toute fois je vous l'accorde j'ai pas donné certaines précisions importantes:
Je calcule le temps de chiffrement du RSA et du AES.
Pour le RSA je traite 245 à la fois
Implémentation JAVA
Merci encore une fois et a+
merci de ne pas quoter inutilement tout le texte!
serait-ce:
"AES 128 bits de clé, 2,58 Mo de fichier à chiffrer ..."
"RSA 2048 bits de clé, 2,58 Mo de fichier à chiffrer ..."
si ce n'est pas une comparaison de chiffrement cela y ressemblait
ou était très mal formulé, choisissez.
je n'ai pas parlé (non plus) de jugement subjectif de valeur.
j'ai dit que la comparaison n'a pas de sens, répéter qu'il est
"plus lent" continue à ne pas avoir de sens puisque les 2
opérations (chiffrement symétrique vs wrapping/signature asym)
ne sont nullement comparables (dire que dessiner un motif au
pinceau est plus lent que peindre uniformément au pistolet
serait aussi peu pertinent).
AES peut être comparé à DES (RCx, ...), RSA peut être comparé
à DSA ou ECDSA.
Sylvain.
Les deux sont des permutations pseudo-aléatoires (enfin, pour le textbook
RSA ce n'est pas vrai mais passons), donc si, la comparaison a un sens.
Après tout, on pourrait se demander pourquoi on n'utilise pas RSA aussi
pour faire du chiffrement symétrique avec les deux parties partageant une
même clef secrète.
J'ai un peu de mal à comprendre la véhémence avec laquelle a été
accueillie cette question. Il est vrai que de prime abord elle méritait
une clarification, mais sachant qu'elle a été apportée, c'est bon, on a
compris qu'il s'agissait juste d'un exercice à vocation pédagogique.
Au passage, je trouve inquiétante l'idée qu'un chiffrement RSA, c'est
forcément avec un exposant de 2 ou 3 bits. Je sais bien que certaines
normes imposent e = 3 ou 65537, mais merci de ne pas en faire une règle
générale (RSA avec petit exposant public a des faiblesses notoires que
n'a pas RSA avec exposant public aléatoire).
AES est une permutation déterministe et RSA un calcul numérique.
je ne comprends pas votre résumé.
"clef secrète" signifiant "algo. symétrique", je ne me demande pas
pourquoi on n'utilise pas RSA.
j'ai un peu de mal à voir où il y aurait une véhémence.
je n'ai pas une généralité de 65537, je l'ai indiqué comme conséquence
à l'hypothèse (non confirmée par le PO) du traitement par une clé
*publique*, si le PO avait utilisé un exposant privé "long" (de l'ordre
de 2048 bits) pour son calcul, il n'aurait pas mis 74 sec pour traiter
10Mo mais plutôt une durée proche de l'heure!
ceci relativisant également la portée de la dite comparaison.
Sylvain.
Je n'arrive pas à ne pas citer tout le texte dites moi comment vous faites.
Je persiste et je suis signe que je fais une comparaison en terme de VITESSE et stop entre AES et RSA.
Dans ce petit exercice, Je n'utilise pas le RSA pour la signature mais bien même s'il n'est pas recommander pour le chiffrement. Alors pourquoi je fais ceci et bien parce que dans le cours on a vu le chiffrement symétrique avec ses avantages et ses inconvénients (comme le transfert de la clé secrète ). Parmi les raisons pour lesquelles la crypto asymétrique à vu le jour c'est de trouver une solution à ce problème de transfert d'où clé publique clé privée or tout n'est pas parfait parmi les inconvénients du RSA il y a le temps de chiffrement. Finalement on a compris qu'il serai mieux de combiner les deux avec la clé symétrique chiffrement du message ensuite avec RSA chiffrement de la clé symétrique
tout ce qui vient d'être dit je souhaite le réaliser moi même donc chiffré un texte avec AES et avec RSA et sortir avec la conclusion que le mieux c'est de combiner les deux.
merci à vous et bonne soirée.
merci vous avez tout compris tester en travaux pratiques quelque aspect du cours.
ben on le sélectionne et on l'efface, tout simplement.
(sauf si vous postez depuis une page ouèbe qui l'empêche peut être).
c'était clair.
c'est un inconvénient, mais il existe des solutions pour chaque type
d'usage.
en effet vous n'utilisez pas la signature (lire la clé privée) pourtant
votre exemple / comparaison devrait inclure le déchiffrement par le
destinataire, celui-ci réalisera un calcul tout à fait équivalent à
une génération de signatures - soit un temps de calcul de 50 à 100 fois
plus important que le chiffrement avec la clé publique.
euh non, la crypto. asymétrique n'est pas née pour répondre au transfert
de clé secrètes, mais elle (dont le RSA) s'y prète assez bien.
c'est en effet comme cela que fonctionne 100% des systèmes (y compris
SSL, y compris échange inter-serveurs, ...).
la clé symétrique est un simple aléa qui est communiqué au destinataire
"wrappé" (chiffré) par sa clé publique.
le "mieux" dépends de l'opération exacte et des contraintes externes;
en ce sens il n'y avait pas de véhémence mais il n'y a pas non plus
de prosélytisme pour un couplage systématique.
si vous souhaitez protéger des informations "courtes" (un fichier d'un
centaine d'octets) vous pouvez tout à fait le chiffrer directement avec
votre clé publique; si, autre cas, le stockage de la clé RSA privée
(qui mérite au moins autant d'attention que celui d'une clé secrète
partagée) ne peut pas être garanti ou encore si le calcul par clé privé
ne peut pas être fait (un PC le fait sans problème, un win-phone un peu
moins aisément), la clé symétrique peut aussi être généré à partir d'un
mot de passe (Cf crypto dite "PBE" (password based encryption)), elle
n'est alors plus directement partagée mais regénérée.
Sylvain.