Pourquoi le chiffrement AES prend-il plus de temps que le déchiffrement?
Pendant que j'étudiais le temps consommé par certaines méthodes, j'ai constaté que le chiffrement prenait plus de temps que le déchiffrement. Est-ce correct? J'utilise AES (les mêmes étapes seront suivies lors de l'enc et dec)
Plusieurs chiffrements de blocs symétriques (en particulier ceux comme AES, DES, Blowfish, RC5) prendront le même temps (avec une erreur de mesure) pour le chiffrement et le déchiffrement, lorsqu'ils fonctionnent sur un seul bloc (par exemple, 128 bits pour AES).
Cependant, il existe plusieurs raisons pour lesquelles il semble différent lors du cryptage/décryptage de plusieurs blocs. Par exemple, avec enchaînement de blocs de chiffrement (CBC), le chiffrement doit être effectué séquentiellement (chiffrer le bloc 0 avant de pouvoir chiffrer le bloc 1 avant de chiffrer le bloc 2 ...), tandis que le déchiffrement peut être parallélisé comme l'étape XOR (avec le bloc de texte chiffré précédent) est effectuée après l'application du chiffrement par bloc.
Voir les diagrammes ci-dessous (XOR est indiqué par un cercle plus ⊕). Pour crypter le deuxième bloc de texte en clair p[1], Vous utilisez c[1] = AES_Encrypt(p[1] XOR c[0]), cela signifie que vous ne pouvez pas générer c[1] Tant que vous n'avez pas fini de générer c[0].
Pendant ce temps, pour décrypter le deuxième bloc de texte chiffré, vous utilisez p[1] = c[0] XOR AES_Decrypt(c[1]). Cela ne dépend pas du bloc précédent de texte en clair p[0] Et peut donc être complètement parallélisé (et peut s'exécuter beaucoup plus rapidement sur les systèmes multicœurs). 
Si vous souhaitez un décryptage et un cryptage rapides, vous pouvez envisager d'utiliser le CTR car il peut être mis en parallèle sur le cryptage et le décryptage.
Vous devriez également vous méfier des tests faussés en raison des caches sur votre système. Si vous décidez au hasard de lire un fichier à partir du disque et de le crypter, il faudra plusieurs millisecondes pour lire chaque morceau du fichier; cependant, la prochaine fois que vous y accéderez, le fichier sera généralement mis en cache en mémoire et accessible beaucoup plus rapidement. Pendant ce temps, pour votre test de décryptage, ce fichier crypté qui a été récemment écrit sur le disque sera probablement toujours dans un cache en mémoire et ne souffrira pas de la peine de lecture à partir du disque.
Synchronisation CTR
$ time openssl aes-256-ctr -e -salt -pass pass:passwd -in Fedora_64-bit.vmdk -out vmdk.encrypted
real 0m58.217s
user 0m5.788s
sys 0m8.493s
$ time openssl aes-256-ctr -e -salt -pass pass:passwd -in Fedora_64-bit.vmdk -out vmdk.encrypted
real 0m34.780s
user 0m4.800s
sys 0m7.748s
$ time openssl aes-256-ctr -e -salt -pass pass:passwd -in Fedora_64-bit.vmdk -out vmdk.encrypted
real 0m34.989s
user 0m4.120s
sys 0m6.444s
$ time openssl aes-256-ctr -d -salt -pass pass:passwd -in vmdk.encrypted -out decrypted
real 0m35.944s
user 0m4.140s
sys 0m7.008s
Les trois premiers chiffrements montrent l'effet du cache disque, où le premier accès à un fichier était beaucoup plus lent que les accès suivants. Cela montre également que pour le CTR, le chiffrement/déchiffrement de cette machine virtuelle 7,4 G a pris environ 35 secondes. (À l'occasion de répétitions, le déchiffrement serait plus rapide ou plus lent).