Les instructions SSE* peuvent aider pour certains algorithmes de crypto ; surtout ceux qui manipulent des mots de 64 bits et font des opérations arithmétiques et logiques avec ces mots. L'effet est surtout sensible en mode 32 bits.
L'exemple typique est SHA-512. L'implémentation de SHA-512 dans OpenSSL est en C, mais, quand elle tourne sur un processeur disposant du jeu d'instruction SSE2, alors elle commute automatiquement vers une implémentation en assembleur utilisant à fond le SSE2. SHA-512 fait des additions, des rotations, et des opérations booléennes bit à bit sur des mots de 64 bits, ce qui est pile-poil dans ce que SSE2 permet de faire. Le gain est impressionnant : ça fait passer SHA-512 de 20 à plus de 80 Mo/s sur la même machine. On ne retrouve pas ce gain en AMD64, car alors les registres "standard" sont en 64 bits et sont en nombre suffisant pour faire le boulot.
Pour Whirlpool, c'est moins clair. Une phase de Whirlpool est exprimée, mathématiquement, comme un ensemble de transformations (dont certaines linéaires) dans un espace vectoriel de dimension 8 sur un corps GF(256). C'est très en dehors de ce que les processeurs savent faire "nativement". Ça s'implémente efficacement en faisant des accès à des tables précalculées : grosso-modo, il faut, pour chaque mot de 64 bits, le découper en huit octets, faire un accès indexé par chacun de ces octets dans huit tables, et faire un XOR des résultats (chaque table -- il y en a 8 -- contient 256 entrées de 64 bits). Il y a 16 mots d'état de 64 bits dans un Whirlpool, et il faut faire ça 10 fois, donc 1280 accès à une table pour un bloc de données (un bloc = 64 octets). À peu près tout le coût d'un Whirlpool est concentré dans ces accès, soit 20 accès par octet en entrée.
Tout ça pour dire que les capacités de calcul de SSE ne seront pas exploitées par Whirlpool ; et il n'y a pas, à ma connaissance, d'opcode SSE (même dans SSE4) pour accéder à une table en mémoire selon un index stocké dans un registre SSE. Il faudra faire une partie du traitement dans les registres entiers usuels. On peut imaginer que les registres SSE serviraient pour le XOR des sorties des tables ; il faudrait que je me penche sur la question sérieusement. À froid, je peux imaginer un gain, mais relativement faible, pour l'usage de SSE2 par rapport à une implémentation 32 bits "simple". Mais SSE4 n'apportera rien en lui-même (par rapport à SSE2), et tous ces gains disparaissent si on passe en mode AMD64 (et les processeurs sachant faire du SSE4 sauront probablement faire aussi de l'AMD64, donc on aurait tort de se priver).
Je ne sais pas si l'usage du SSE est posible dans le noyau Linux. Dans le temps, on ne pouvait pas utiliser la FPU dans le noyau. Ça pourrait simplifier la question.
Usuellement, les cryptographes travaillent dans l'autre sens : ils observent l'existence de nouveaux opcodes, et ils se demandent comment s'en servir pour inventer de nouvelles fonctions qui en profiteront.
[^] # Re: NESSIE
Posté par Thomas Pornin . En réponse à la dépêche Nouvelles fonctions de hachage. Évalué à 3.
L'exemple typique est SHA-512. L'implémentation de SHA-512 dans OpenSSL est en C, mais, quand elle tourne sur un processeur disposant du jeu d'instruction SSE2, alors elle commute automatiquement vers une implémentation en assembleur utilisant à fond le SSE2. SHA-512 fait des additions, des rotations, et des opérations booléennes bit à bit sur des mots de 64 bits, ce qui est pile-poil dans ce que SSE2 permet de faire. Le gain est impressionnant : ça fait passer SHA-512 de 20 à plus de 80 Mo/s sur la même machine. On ne retrouve pas ce gain en AMD64, car alors les registres "standard" sont en 64 bits et sont en nombre suffisant pour faire le boulot.
Pour Whirlpool, c'est moins clair. Une phase de Whirlpool est exprimée, mathématiquement, comme un ensemble de transformations (dont certaines linéaires) dans un espace vectoriel de dimension 8 sur un corps GF(256). C'est très en dehors de ce que les processeurs savent faire "nativement". Ça s'implémente efficacement en faisant des accès à des tables précalculées : grosso-modo, il faut, pour chaque mot de 64 bits, le découper en huit octets, faire un accès indexé par chacun de ces octets dans huit tables, et faire un XOR des résultats (chaque table -- il y en a 8 -- contient 256 entrées de 64 bits). Il y a 16 mots d'état de 64 bits dans un Whirlpool, et il faut faire ça 10 fois, donc 1280 accès à une table pour un bloc de données (un bloc = 64 octets). À peu près tout le coût d'un Whirlpool est concentré dans ces accès, soit 20 accès par octet en entrée.
Tout ça pour dire que les capacités de calcul de SSE ne seront pas exploitées par Whirlpool ; et il n'y a pas, à ma connaissance, d'opcode SSE (même dans SSE4) pour accéder à une table en mémoire selon un index stocké dans un registre SSE. Il faudra faire une partie du traitement dans les registres entiers usuels. On peut imaginer que les registres SSE serviraient pour le XOR des sorties des tables ; il faudrait que je me penche sur la question sérieusement. À froid, je peux imaginer un gain, mais relativement faible, pour l'usage de SSE2 par rapport à une implémentation 32 bits "simple". Mais SSE4 n'apportera rien en lui-même (par rapport à SSE2), et tous ces gains disparaissent si on passe en mode AMD64 (et les processeurs sachant faire du SSE4 sauront probablement faire aussi de l'AMD64, donc on aurait tort de se priver).
Je ne sais pas si l'usage du SSE est posible dans le noyau Linux. Dans le temps, on ne pouvait pas utiliser la FPU dans le noyau. Ça pourrait simplifier la question.
Usuellement, les cryptographes travaillent dans l'autre sens : ils observent l'existence de nouveaux opcodes, et ils se demandent comment s'en servir pour inventer de nouvelles fonctions qui en profiteront.