Le test a été réalisé sur un Core i3-4150 : 2 cœurs Hyper-Threading, donc au moins quand je suis en multi 8 bascule d'un processus à un autre.

En effet (ce sont bien 8 processus et non pas 8 threads), et sur ce test Ubuntu qui a CONFIG_HZ=250 (sur le kernel générique) est probablement légèrement moins impacté que Fedora par exemple qui a CONFIG_HZ=1000 donc devrait basculer plus souvent.

Par contre tu saurais peut-être me dire pourquoi avec OpenSSL, aes-128-cbc et aes-256-cbc voit ses performances doublées quand on passe de 2 threads à 4threads alors que le CPU n'a que 2 cœurs ! Là l'Hyper-Threading permet de doubler les performances.

Au contraire, avec aes-128-gcm etaes-256-gcm il n'y a aucun gain avec l''Hyper-Threading : les performances sont les mêmes quand on passe de 2 threads à 4threads.[/size]

Déjà, il faut faire attention, si la fréquence du CPU n'est pas fixée, augmenter la charge peut faire baisser le turbo.
L'hyperthreading est utile :
 - quand on a des tâches qui attendent la mémoire
 - quand on a trop de dépendances dans le flux d'instructions qui empêchent d'extraire le maximum de parallélisme
 - dans certains cas où certaines unités sont saturées et d'autres inutilisées (cas de deux tâches différentes, ce qui n'est pas le cas ici)

Ici, on est dans le second cas, ce qui s'explique en regardant les algorithmes :
 - https://fr.wikipedia.org/wiki/Mode_d%27op%C3%A9ration_(cryptographie)#Encha%C3%AEnement_des_blocs_:_%C2%AB_Cipher_Block_Chaining_%C2%BB_(CBC)

Un des points négatifs de CBC étant qu'il ne peut pas être parallélisé étant donné que le bloc courant nécessite que le précédent soit chiffré. Il est donc séquentiel.

- https://fr.wikipedia.org/wiki/Galois/Counter_Mode
Le GCM est dérivé du CTR : les opérations (AES+XOR) sur des blocs successifs peuvent être réalisées en même temps car il n'y a aucune dépendance.

D'ailleurs avec openssl, aes-128-ctr donne les même performances que aes-128-gcm (la limite d'exécution des instructions AES-NI probablement).
Mais le code AES-GCM fait aussi l'authentification (GHASH), alors que le code AES-CTR (comme AES-CBC) ne fait que chiffrer.
C'est pour ça que si on veut comparer les deux dans un contexte TLS, il faut faire :
 - openssl speed -elapsed -evp aes-128-cbc-hmac-sha1 (850Mo/s pour moi)
 - openssl speed -elapsed -evp aes-128-cbc-hmac-sha256 (440Mo/s pour moi)
 - openssl speed -elapsed -evp aes-128-gcm (5.5Go/s)
=> On voit tout l'intérêt du mode GCM.

Compétemment hors sujet, mais tu en pense quoi de chacha20-poly1305 ?
Il semble plus récent et mieux adaptés pour des CPU sans support de l'AES.

Je ne suis pas expert sécurité, donc je me garderais de porter un jugement sur la résistance potentielle aux attaques de ce chiffrement.
C'est une solution récente (donc qui a à la fois bénéficié de l'avancée des recherches en cryptographie, mais sur laquelle on a forcèment moins de recul), conçue par un chercheur reconnu, et qui semble être à la mode.

Concernant les performances, c'est effectivement un bon choix dès qu'il n'y a pas d'AES accéléré. C'est même la seule option pour Wireguard par exemple (ce qui est plus critiquable car beaucoup de CPU ARMv8 ont les extensions crypto qui accélèrent l'AES, alors que chacha20-poly1305 doit se contenter d'une implèmentation qui certes utilise NEON mais est plus lente).

N'y a-t-il pas de nombreux "fix" hardware qui sont bien plus dommageable que les "fix" software ?
Je parle en terme de performance

Attention : tu dois aussi mettre à jour le BIOS de ton PC pour que cela puisse fonctionner...

Ça, je ne sais pas comment faire. 

D'ailleurs avec openssl, aes-128-ctr donne les même performances que aes-128-gcm (la limite d'exécution des instructions AES-NI probablement).
Mais le code AES-GCM fait aussi l'authentification (GHASH), alors que le code AES-CTR (comme AES-CBC) ne fait que chiffrer.
C'est pour ça que si on veut comparer les deux dans un contexte TLS, il faut faire :
 - openssl speed -elapsed -evp aes-128-cbc-hmac-sha1 (850Mo/s pour moi)
 - openssl speed -elapsed -evp aes-128-cbc-hmac-sha256 (440Mo/s pour moi)
 - openssl speed -elapsed -evp aes-128-gcm (5.5Go/s)
=> On voit tout l'intérêt du mode GCM.

J'ai commencé mes tests sur un nouveau processeur (enfin un très vieux : AMD Sempron 2800+, Modèle Palermo 90nm sur Socket 754 : c'est le premier Sempron 64bits.


Coté système d'exploitation, j'ai mis un Ubuntu 19.04 64bits nouvellement installé.

Mes tests habituels passent bien :
openssl speed -elapsed -evp aes-128-cbc : 109,5 Mo/s
openssl speed -elapsed -evp aes-256-cbc : 81,4 Mo/s
openssl speed -elapsed -evp aes-128-gcm : 36,8 Mo/s
openssl speed -elapsed -evp aes-256-gcm : 28,2 Mo/s
openssl speed -elapsed -evp chacha20-poly1305 : 168,6 Mo/s

Exemple :
$ openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 6409762 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 2032042 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 539577 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 309662 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 40109 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 19996 aes-128-cbc's in 3.00s
OpenSSL 1.1.1b  26 Feb 2019
built on: Wed Apr  3 10:50:23 2019 UTC
options:bn(64,64) rc4(8x,int) des(int) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-uEA50R/openssl-1.1.1b=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc      34185.40k    43350.23k    46043.90k   105697.96k   109524.31k   109204.82k
Mais impossible de faire :
openssl speed -elapsed -evp aes-128-cbc-hmac-sha1
openssl speed -elapsed -evp aes-128-cbc-hmac-sha256

$ openssl speed -elapsed -evp aes-128-cbc-hmac-sha1
speed: aes-128-cbc-hmac-sha1 is an unknown cipher or digest
$ openssl speed -elapsed -evp aes-128-cbc-hmac-sha256
speed: aes-128-cbc-hmac-sha256 is an unknown cipher or digest