Pourquoi AES n'est pas utilisé pour le hachage sécurisé, au lieu de SHA-x?
Autant que je sache, AES est considéré comme extrêmement sécurisé. (J'ai lu quelque part qu'il ne serait certainement pas cassé dans les 20 prochaines années, mais je ne sais toujours pas si l'auteur était sérieux.)
DES n'est toujours pas si mal pour un vieux chiffrement, et 3DES est toujours utilisé (peut-être pas autant, mais au moins je vois 3DES dans about: config dans Firefox).
Il semble que les (bons) cyphers de bloc soient approuvés par la communauté cryptographique.
OTOH, de nombreux problèmes avec les fonctions de hachage cryptographiques sont découverts.
Du point de vue du non-crypto-spécialiste: les fonctions de hachage et les cyphers symétriques sont vraiment la même chose: une fonction "aléatoire" (avec différentes entrées et sorties).
Alors, pourquoi ne pas utiliser uniquement AES pour le hachage? Cela semble être la chose la plus évidente à faire pour obtenir la sécurité élevée d'AES pour le hachage. En prime, les implémentations matérielles d'AES pourraient-elles aider?
Y a-t-il une explication simple de la vraie différence entre les fonctions de hachage et les cyphers symétriques?
Un chiffrement par bloc a une clé; le secret de la clé est ce sur quoi repose la sécurité du chiffrement. D'un autre côté, une fonction de hachage n'a pas de clé du tout, et il n'y a pas de "données secrètes" sur lesquelles la sécurité de la fonction de hachage doit être construite.
Un chiffrement par bloc est réversible : si vous connaissez la clé, vous pouvez déchiffrer ce qui a été chiffré. Techniquement, pour une clé donnée, un chiffrement par bloc est une permutation de l'espace des valeurs de bloc possibles. Les fonctions de hachage sont censées être non réversibles et ne sont en aucun cas des permutations.
Un chiffrement par blocs fonctionne sur des blocs de taille fixe (blocs de 128 bits pour AES), à la fois pour l'entrée et la sortie. Une fonction de hachage a une sortie de taille fixe, mais doit accepter des entrées arbitrairement grandes.
Les chiffres de bloc et les fonctions de hachage sont donc des animaux vraiment différents; plutôt que d'essayer de les différencier, il est plus facile de voir ce qu'ils ont en commun: à savoir que les personnes qui savent concevoir un chiffrement par bloc sont également raisonnablement douées pour concevoir des fonctions de hachage, parce que les outils mathématiques d'analyse sont similaires (assez beaucoup d'algèbre linéaire et de fonctions booléennes, vraiment).
C'est parti pour des définitions plus formelles:
Un chiffrement par bloc est une famille de permutations sélectionnées par une clé. Nous considérons l'espace [~ # ~] b [~ # ~] de n - blocs de bits pour une valeur fixe de n ; la taille de [~ # ~] b [~ # ~] est alors 2n. Les clés sont des valeurs d'un espace [~ # ~] k [~ # ~] , généralement un autre espace de séquences de m bits ( m n'est pas nécessairement égal à n ). Une touche k sélectionne une permutation parmi les 2n! permutations possibles de [~ # ~] b [~ # ~] .
Un chiffrement par bloc est considéré comme sûr tant qu'il est impossible de le distinguer d'un calcul d'une permutation qui a été choisie de façon uniforme et aléatoire parmi les 2n! permutations possibles. Pour modéliser cela, imaginez une situation où un attaquant a accès à deux boîtes noires, l'une mettant en œuvre le chiffrement par bloc avec une clé que l'attaquant ne connaît pas, et l'autre étant une permutation vraiment aléatoire. Le but de l'attaquant est de dire lequel est lequel. Il peut faire chiffrer ou déchiffrer chaque boîte quelles que soient les données qu'il souhaite. Une attaque possible consiste à essayer toutes les clés possibles (il y a 2m ces clés) une seule est trouvée, ce qui donne les mêmes valeurs que l'une des cases; cela a un coût moyen 2m-1 invocations du chiffre. Un chiffrement de bloc sécurisé en est un tel que cette attaque générique est la meilleure attaque possible.
L'AES est défini sur des blocs de 128 bits ( n = 128) et des clés de 128, 192 et 256 bits.
Une fonction de hachage est une fonction unique, entièrement définie et calculable qui prend en entrée des séquences de bits de longueur arbitraire et génère des valeurs de longueur fixe r (par exemple r = 256 bits pour SHA-256). Il n'y a pas de clé, pas de famille de fonctions, juste une fonction unique que n'importe qui peut calculer.
Une fonction de hachage h est considérée comme sécurisée si:
- Il est impossible de trouver des préimages par calcul: étant donné une valeur de bit r - x , il n'est pas possible de trouver m tel que h (m) = x .
- Il est impossible sur le plan informatique de trouver des secondes préimages: étant donné m , il n'est pas possible de trouver m ' distinct de m , tel que h (m) = h (m ') .
- Il est impossible sur le plan informatique de trouver des collisions: il n'est pas possible de trouver m et m ', distincts les uns des autres, de sorte que h (m) = h (m ') .
Il existe des attaques génériques qui peuvent trouver des préimages, des secondes préimages ou des collisions, avec des coûts, respectivement, 2r, 2r et 2r/2. La sécurité réelle ne peut donc être atteinte que si r est suffisamment grand pour que 2r/2 est un coût extrêmement élevé. En pratique, cela signifie que r = 128 (une fonction de hachage de 128 bits telle que MD5) n'est pas insuffisante .
De manière informelle, il est bon que la fonction de hachage "ressemble" à une sélection aléatoire et uniforme parmi les fonctions possibles qui acceptent les mêmes entrées. Mais c'est une propriété mal définie car nous parlons d'une fonction unique (les probabilités sont toujours implicitement des moyennes et des expériences répétées; vous ne pouvez pas vraiment avoir de probabilités avec une seule fonction). De plus, être une fonction aléatoire n'est pas exactement la même chose qu'être résistant aux collisions et aux préimages; c'est le débat sur le Random Oracle Model .
Néanmoins, il est possible de construire une fonction de hachage à partir d'un chiffrement par bloc. C'est ce que fait la construction Merkle-Damgård . Cela implique d'utiliser le message d'entrée comme clé du chiffrement de bloc; donc le chiffrement par bloc n'est pas du tout utilisé comme il était censé l'être. Avec AES, cela s'avère décevant:
- Il en résulte une fonction de hachage avec une sortie 128 bits, ce qui est trop petit pour la sécurité contre la technologie disponible en 2011.
- La sécurité de la fonction de hachage repose alors sur l'absence de attaques par clé associée sur le chiffrement de bloc. Les attaques par clé associée n'ont pas vraiment de signification pratique sur un chiffrement par bloc lorsqu'il est utilisé pour le chiffrement; par conséquent, AES n'a pas été conçu pour résister à de telles attaques, et, en effet, AES a a quelques faiblesses à cet égard - pas un souci de chiffrement, mais une grande inquiétude si AES doit être utilisé dans une construction Merkle-Damgård.
- La performance ne sera pas bonne.
La fonction de hachage Whirlpool est une conception qui s'appuie sur un chiffrement par bloc inspiré de l'AES - pas le vrai. Ce chiffrement de bloc a un calendrier de clés beaucoup amélioré (et plus lourd), qui résiste aux attaques de clés associées et le rend utilisable comme noyau d'une fonction de hachage. De plus, ce chiffrement de bloc fonctionne sur des blocs de 512 bits, pas sur des blocs de 128 bits. Whirlpool est considéré comme sécurisé. Le bain à remous est connu pour être très lent, donc personne ne l'utilise.
Certaines conceptions de fonctions de hachage plus récentes ont tenté de réutiliser les parties de l'AES - pour être précis, d'utiliser une opération interne qui correspond bien à la AES-NI les instructions des derniers processeurs Intel et AMD. Voir par exemple ECHO et SHAvite- ; ces deux fonctions ont toutes deux reçu un peu de visibilité dans le cadre de la compétition SHA- et sont jugées "raisonnablement sûres". Il y a très rapide sur les processeurs Intel et AMD récents. Sur d'autres architectures plus faibles, si les performances des fonctions de hachage ont une certaine chance d'avoir de l'importance, ces fonctions sont assez lentes.
Il existe d'autres constructions qui peuvent faire une fonction de hachage à partir d'un chiffrement de bloc, par ex. celui utilisé dans Skein ; mais ils ont également tendance à nécessiter des blocs plus grands que ce sur quoi l'AES est défini.
Résumé: non seulement les chiffrements par blocs et les fonctions de hachage sont très différents; mais l'idée de construire une fonction de hachage à partir de l'AES s'avère être d'une validité discutable. Ce n'est pas facile, et la taille limitée des blocs AES est le principal obstacle.
La réponse de base est qu'il s'agit de différents types d'algorithmes. AES est un algorithme à clé symétrique. Vous ne pouvez pas l'utiliser dans le même rôle que RSA (un algorithme à clé publique) ou SHA-256 (un algorithme de hachage). Ce sont différents systèmes conçus avec des propriétés et des faiblesses très différentes.
Pourtant, j'ai fait une pause et bien au sérieux à propos de cette idée pour l'expliquer en plus de simplement dire: "C'est comme ça." Après tout, un hachage au sens universel est une représentation reproductible de données dans une taille fixe ou réduite. AES peut fournir cela via le mode CBC. Pourtant, il y a plus de propriétés à un hachage sécurisé qu'une simple réduction.
Un algorithme de hachage sécurisé est un système à sens unique. AES chiffre et déchiffre de la même manière (chiffrement symétrique), et vous pouvez faire un mappage 1-1 pour chaque bloc ce qui se passera avec une clé donnée. Sauf si les données sont enchaînées et donc avec perte, vous pouvez simplement décrypter le "hachage" AES en données source.
On ne peut pas raisonnablement inverser un processus SHA autre que d'essayer simplement différentes données d'entrée. Pour les raisons que vous ne pouvez pas utiliser SHA-x pour chiffrer quelque chose, vous ne pouvez pas utiliser AES pour hacher quelque chose.
Y a-t-il une explication simple de la vraie différence entre les fonctions de hachage et les cyphers symétriques?
- Un chiffre est réversible, une fonction de hachage n'est pas
- La longueur de la sortie d'un chiffre dépend de la longueur de l'entrée; une fonction de hachage produit la même longueur de sortie quelle que soit l'entrée
- Un changement de bit unique n'importe où dans une fonction de hachage cryptographique produit un changement en cascade (spectaculaire) dans la sortie de hachage. En règle générale, ce n'est pas le cas pour les chiffres.
- Un chiffrement nécessite une clé, un hachage ne
La conception et le but des deux sont fondamentalement différents et ils ne sont pas interchangeables.
Vous pouvez essentiellement transformer n'importe quel chiffrement de bloc en une fonction de hachage en utilisant la construction Merkle-Damgard et vous pouvez essentiellement transformer n'importe quelle fonction de hachage en un chiffrement de bloc en utilisant des réseaux Feistel si vous définissez la fonction Feistel F de la manière suivante.
F(half_block, round_key) = hash(concatenate(half_block, round_key))
Mais il est assez inefficace (prend beaucoup de temps à calculer), car F est déjà cher à calculer (c'est un algorithme itératif utilisant par exemple 80 "tours" internes dans le cas de SHA-512) et pour la structure Feistel, F lui-même est itéré plusieurs fois. Supposons que vous ayez un réseau Feistel à 20 étages avec une fonction ronde de 80 tours F, vous effectuez 1600 SHA-2 "tours" par bloc. Cela conduit également à des tailles de bloc assez grandes (le double de la taille de la sortie de la fonction de hachage), e. g. Chiffrement par blocs de 1024 bits si vous deviez utiliser SHA-512 comme fonction de hachage.
Mais en pratique, ce n'est pas nécessairement "précaire". C'est juste que les "chiffrements de blocs" facilement disponibles (plutôt les permutations pseudo-aléatoires - pas la permutation comme dans la permutation de bits/octets, mais la permutation dans le sens de la cartographie bijective entre "tous les blocs d'entrée possibles" et "tous les blocs de sortie possibles") sont bien plus efficace, plus largement utilisé et donc plus minutieusement analysé pour les propriétés de bonnes permutations pseudo-aléatoires. Si vous avez une puissance de calcul à gaspiller, utilisez SHA-512 dans un réseau Feistel comme chiffrement par bloc. Les chances sont au moins qu'il ne soit pas moins sécurisé que AES (à condition que vous ajoutiez un bon programme de clés pour dériver les "clés rondes"), mais cela prendra lots de cycles CPU pour traiter un bloc.
M. Abel a raison. Un autre exemple d'AES utilisé comme hachage est AES-CBC ou AES-PCBC.
Si CBC ou PCBC ou même CFB est exécuté sur un "fichier" avec et sans erreur, le bloc final sera différent.
C'est inefficace, mais cela peut être fait. La logique est: "Si tout ce que vous avez est un marteau, tout ressemble à un clou." Il en va de même pour AES. Il peut y avoir de meilleures façons de hacher, mais si tout ce que vous avez est AES. . .