Devrions-nous utiliser SHA3? (2017)
Cette question est un en double , mais je pense que c'est nécessaire étant donné la question. L'original a été publié en 2012: il y a environ 5 ans avant que le NIST n'ait même publié la spécification finale.
La question est plus ou moins la même que l'original. SHA3 a-t-il été suffisamment étudié pour être considéré comme sûr pour des situations de grande valeur, et y a-t-il un avantage à l'utiliser par rapport à son prédécesseur, SHA2. Fondamentalement, devrions-nous l'utiliser?
Je ne suis pas convaincu que nous devrions . SHA-3 en a Nicefeatures pour sûr, mais pour les raisons que j'énumère ci-dessous, je suggérerais probablement d'utiliser SHA-2 ou BLAKE2 pour le moment. Même NIST eux-mêmes disent:
Actuellement, il n'est pas nécessaire de transférer les applications de SHA-2 à SHA-3.
Cela dit, vous pensez peut-être encore "pourquoi pas"?
SHA- n'est pas encore compatible FIPS-140 . Sans FIPS 140- , il est hors de portée des agences gouvernementales non militaires et des entrepreneurs gouvernementaux. Si vous êtes inquiet à propos de la conformité FIPS, vous êtes bloqué avec la suite SHA-2 pour l'instant.SHA-3 était inclus dans FIPS 140-2 Annexe A, et même si ce document indique toujours "Brouillon" sur la page de garde, il semble avoir été finalisé via cesdeux pages.- Performances . SHA-3 est incroyablement rapide dans les implémentations matérielles (ASIC) . Cependant, il est beaucoup plus lent dans les logiciels fonctionnant sur des CPU avec des registres limités, ce qui signifie qu'il est généralement moins utile *. Son principal concurrent (au moins, à la suite de la compétition) est BLAKE2, qui s'est avéré beaucoup plus rapide sur les processeurs généraux et est parfois préféré à Keccak/SHA-3 pour autre raisons . Bien que je pense que le NIST sous-estime les différences de performances logicielles entre les finalistes, leurs commentaires sur les performances lors de la dernière phase de prise de décision peuvent être utiles pour fournir un contexte. De NISTIR 7896 , section 3.2:
une. Les cinq finalistes fonctionnent assez bien pour être utilisables dans la plupart des applications.
b. Aucun des cinq finalistes n'est le meilleur pour chaque application, et aucun n'offre d'améliorations vraiment convaincantes par rapport aux algorithmes SHA-2.
c. Les algorithmes basés sur ARX, BLAKE et Skein, fonctionnent extrêmement bien dans les logiciels.
ré. Keccak a un net avantage en termes de performances débit/zone dans les implémentations matérielles.
e. Grøstl et JH sont considérablement plus lents que les trois autres algorithmes dans la plupart des implémentations logicielles. - Prudence potentiellement inutile . Il convient également de noter que BLAKE a reçu des remarques négatives en raison de à quel point il était similaire à SHA-2. Par prudence, cela a aidé Keccak/SHA-3 à remporter la compétition. De NISTIR 7896 , section 3.4:
b. Étant donné que SHA-2 est une conception basée sur ARX avec un calendrier clé, il a des éléments de conception importants en commun avec BLAKE et Skein, bien qu'aucun ne soit étroitement lié à SHA-2. Cependant, les outils de cryptographie qui s'appliqueront à SHA-2 à l'avenir semblent plus susceptibles de s'appliquer à BLAKE ou Skein qu'aux trois autres finalistes.
* Rappelez-vous que nous discutons ici des fonctions de hachage cryptographique, pas nécessairement des fonctions de hachage de mot de passe ou des KDF.
Un peu plus de lecture qui peut valoir le coup: