
L’algorithme Keccak désigne une famille de fonctions de hachage cryptographiques permettant de transformer des données d’entrée de toute taille en une empreinte numérique de longueur fixe. Il constitue le socle du standard SHA-3 et s’impose comme une référence dans les applications blockchain.
Une fonction de hachage fonctionne comme une « machine à empreintes » : une même entrée produit systématiquement la même sortie, mais il est pratiquement impossible de retrouver l’entrée initiale à partir de la sortie seule. Keccak autorise différentes longueurs de sortie, le format 256 bits (Keccak-256) étant le plus répandu. Ce format fixe facilite la vérification, l’indexation et les contrôles de cohérence.
Keccak joue un rôle central en tant que « machine à empreintes » pour des systèmes comme Ethereum, où il sous-tend des opérations clés telles que la génération d’adresses, la sélection des fonctions des smart contracts et l’indexation des journaux d’événements.
Par exemple, sur les plateformes comme Gate, lors d’un dépôt d’ETH, l’adresse commençant par « 0x » est générée en hachant la clé publique avec Keccak-256 puis en sélectionnant les 20 derniers octets. Pour les appels de contrat, le sélecteur de fonction est obtenu en appliquant Keccak-256 à la signature de la fonction et en extrayant les 4 premiers octets. Les journaux d’événements exploitent Keccak pour produire des topics et accélérer la recherche.
Keccak repose sur une « construction éponge ». Comme une éponge, il « absorbe » d’abord les données d’entrée pour mélanger l’état interne, puis « essore » la sortie de hachage désirée.
Étape 1, Absorption : Le message d’entrée est découpé en blocs, qui sont XORés dans la « zone inscriptible » de l’état—à l’image de l’eau absorbée par une éponge qui s’intègre à l’état.
Étape 2, Permutation : Une fonction de permutation (Keccak-f) opère sur plusieurs cycles pour mélanger les bits de l’état. Ce « shuffle » réversible s’exécute généralement sur 24 tours pour Keccak-f[1600].
Étape 3, Essorage : La sortie est extraite de la « zone lisible » de l’état. Pour des sorties plus longues, il faut appliquer des permutations supplémentaires avant d’extraire davantage de données—comme essorer une éponge pour obtenir plus d’eau.
Avec les paramètres de Keccak-256, l’état interne totalise 1 600 bits, répartis en un débit (zone lecture/écriture) de 1 088 bits et une capacité (tampon de sécurité) de 512 bits. Plus la capacité est élevée, plus la sécurité est renforcée.
Quatre usages principaux de Keccak dans Ethereum : la génération d’adresses, les sélecteurs de fonctions, les topics d’événements et l’indexation des structures de données.
La distinction principale entre Keccak et SHA3 réside dans leurs paramètres de padding (« séparation de domaine »). SHA3-256 utilise le suffixe 0x06, alors que Keccak-256 courant dans Ethereum utilise 0x01.
Conséquence : des entrées identiques produisent des sorties différentes selon Keccak-256 ou SHA3-256. En développement ou en audit, il est impératif de vérifier si l’on utilise « Keccak-256 » ou « SHA3-256 »—ces fonctions ne sont pas interchangeables. Lors de la standardisation SHA-3 par le NIST en 2015, ce changement de séparation de domaine a été introduit (source : NIST, 2015).
Première étape : Déterminez si votre entrée est en bytes ou en texte. Pour une chaîne de caractères, encodez toujours en UTF-8 ; pour une chaîne hexadécimale, convertissez-la en bytes bruts sans inclure le préfixe « 0x » dans les données.
Deuxième étape : Sélectionnez la fonction adéquate. Dans l’EVM, keccak256 (Keccak-256) est la référence. Certaines bibliothèques nomment SHA3-256 « sha3 »—vérifiez la documentation et les versions pour éviter toute confusion.
Troisième étape : Validez les résultats par recoupement. Utilisez deux bibliothèques ou outils indépendants pour calculer les hachages et vérifiez leur concordance ; des sélecteurs connus comme « transfer(address,uint256) » donnant « 0xa9059cbb » servent de test.
Considérez les hachages comme des empreintes irréversibles dans vos processus—ils ne servent ni au chiffrement ni à la génération de nombres aléatoires. Pour contrer les attaques par table arc-en-ciel, ajoutez systématiquement un salt aléatoire avant le hachage et hachez l’ensemble salt et données.
Trois écueils principaux : différences de padding, erreurs d’encodage, et mauvaise utilisation dans les applications.
La sécurité de Keccak repose sur sa construction éponge et son paramètre de capacité. Pour Keccak-256, la résistance aux collisions est d’environ 2^128 opérations ; la résistance à la pré-image atteint environ 2^256 opérations.
Au 01 janvier 2025, aucune attaque pratique de collision ou de pré-image n’a été recensée sur les paramètres standards ; la recherche cible surtout des variantes à nombre de tours réduit ou des limites théoriques. Côté performance, les bibliothèques majeures intègrent des implémentations CPU/GPU optimisées pour un haut débit ; l’accélération matérielle (ASIC, etc.) progresse pour les usages intensifs.
Keccak restera un pilier de la sécurité des systèmes, au cœur de SHA-3 ; dans l’écosystème EVM, il demeure fondamental pour les adresses, sélecteurs et l’indexation des logs. Avec la montée de l’accélération matérielle et l’amélioration des bibliothèques, performance et outils continueront d’évoluer. Certains nouveaux usages (notamment les zero-knowledge proofs) pourraient adopter des hachages alternatifs comme Poseidon, sans remettre en cause la stabilité de Keccak pour l’empreinte et l’indexation généralistes. Pour les développeurs, il suffit de distinguer Keccak-256 de SHA3-256 et de gérer rigoureusement encodage et tests pour garantir la fiabilité de Keccak comme outil bas niveau.
Sur Ethereum, Keccak-256 sert à générer les adresses de compte—en hachant la clé publique avec Keccak-256 puis en sélectionnant les 20 derniers octets comme adresse. Si vous utilisez Gate ou une application de portefeuille, ce processus est automatisé ; pour le développement de smart contracts, exploitez la fonction keccak256() de Solidity. Testez d’abord des bibliothèques comme Web3.js pour observer comment le hachage convertit des données de longueur variable en résultats fixes de 256 bits.
Cela provient le plus souvent de différences d’encodage des données d’entrée. Keccak-256 attend des données en bytes—lorsque vous saisissez des chaînes de texte, les outils peuvent gérer l’encodage différemment (UTF-8 vs ASCII). La solution : standardisez votre encodage et spécifiez le format d’entrée lors du développement ; les plateformes comme Gate fournissent des instructions claires. Vérifiez aussi que vous utilisez Keccak-256 ou SHA3-256—leurs sorties diffèrent même pour une entrée identique.
Keccak-256 intervient dans de nombreux cas d’usage des smart contracts : vérification de l’intégrité des données (hachage des transactions pour comparaison), génération d’identifiants uniques (hachage de paramètres combinés), ou gestion des accès (stockage d’informations sensibles sous forme de hachage plutôt qu’en clair). Certains contrats hachent les données utilisateur avant stockage pour éviter d’exposer les valeurs brutes. Cette polyvalence fait de Keccak un outil fondamental du Web3—gardez à l’esprit que le hachage est irréversible : il est impossible de reconstituer les données initiales à partir du hachage.
Non. En tant qu’utilisateur Web3 ou développeur débutant, il suffit de retenir que « Keccak est une fonction de hachage unidirectionnelle—une entrée identique produit une sortie identique ». L’étude approfondie de la cryptographie reste optionnelle (pour les audits de sécurité ou la recherche) ; la plupart des développeurs se contentent d’appeler les fonctions des bibliothèques comme keccak256 de Solidity. Commencez par expérimenter sur des cas concrets comme la signature ou la génération d’adresse via Gate ou sur testnet.
Lors d’un appel à Keccak depuis du code hors chaîne (front-end ou back-end), vérifiez que la version de la bibliothèque correspond à celle utilisée on-chain—généralement Keccak-256. Privilégiez les bibliothèques standard telles que Web3.js ou ethers.js, qui intègrent Keccak correctement par défaut. Soyez attentif à la sérialisation des données—si vous générez des hachages hors chaîne pour vérification on-chain, les méthodes de sérialisation (comme l’encodage ABI) doivent être strictement identiques. Testez systématiquement dans des environnements dédiés, notamment pour les signatures ou la vérification de contrats.


