Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

temps d'exécution du AES et du RSA

38 réponses
Avatar
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.

10 réponses

1 2 3 4
Avatar
Erwan David
kabina écrivait :

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.



ç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é
Avatar
kabina
Erwan David a écrit le 13/06/2009 à 20h02 :
kabina écrivait :

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.




ç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+
Avatar
Sylvain SF
kabina a écrit :
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



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.

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



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.).

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)



pareil.

A votre avis est ce que c'est cohérent !!!!



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.
Avatar
kabina
Sylvain SF a écrit le 14/06/2009 à 02h18 :
kabina a écrit :
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




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.

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




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.).

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)




pareil.

A votre avis est ce que c'est cohérent !!!!




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+
Avatar
Sylvain SF
kabina a écrit :

tout d'abord je vous remercie de votre aide.



merci de ne pas quoter inutilement tout le texte!

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 !!!!!!!!!!!



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.

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.



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.
Avatar
Mehdi Tibouchi
Sylvain SF wrote in message <4a352b95$0$12617$:

je n'ai pas parlé (non plus) de jugement subjectif de valeur.
j'ai dit que la comparaison n'a pas de sens



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).
Avatar
Sylvain SF
Mehdi Tibouchi a écrit :
Sylvain SF wrote in message <4a352b95$0$12617$:
je n'ai pas parlé (non plus) de jugement subjectif de valeur.
j'ai dit que la comparaison n'a pas de sens



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.



AES est une permutation déterministe et RSA un calcul numérique.
je ne comprends pas votre résumé.

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.



"clef secrète" signifiant "algo. symétrique", je ne me demande pas
pourquoi on n'utilise pas RSA.

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.



j'ai un peu de mal à voir où il y aurait une véhémence.

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).



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.
Avatar
kabina
kabina a écrit le 13/06/2009 à 20h00 :
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.


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.
Avatar
kabina
Mehdi Tibouchi a écrit le 14/06/2009 à 21h35 :
Sylvain SF wrote in message <4a352b95$0$12617$:

je n'ai pas parlé (non plus) de jugement subjectif de valeur.
j'ai dit que la comparaison n'a pas de sens




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).


merci vous avez tout compris tester en travaux pratiques quelque aspect du cours.
Avatar
Sylvain SF
kabina a écrit :



Je n'arrive pas à ne pas citer tout le texte dites moi comment vous faites.



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).

Je persiste et je suis signe que je fais une comparaison en terme de VITESSE et
stop entre AES et RSA.



c'était clair.

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 ).



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.

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.



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.

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



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.

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.



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.
1 2 3 4