Hashcode : clé de signature (condensat, empreinte), par une fonction de hachage, d'un contenu (un fichier), sans jamais tenir compte de son enveloppe.

cr  01.04.2012      r+  22.10.2024      r-  22.10.2024      Pierre Pinard.         (Alertes et avis de sécurité au jour le jour)

Hashcode (Condensat en français) désigne le calcul de l'empreinte du contenu d'un fichier, selon divers algotithmes.

Un « hashcode » est une valeur obtenue par application d'un algorithme de calcul sur le contenu d'un objet (fichier …), sans tenir compte de son enveloppe.

Action rapide

Le moyen le plus simple et rapide d'obtenir un/des hashcode(s) du contenu d'un fichier, selon de nombreux algorithmes, est d'installer HashTab. Une fois installé, un simple clic droit sur un nom de fichier, dans l'explorateur de fichiers de Windows Propriétés, fait apparaître l'onglet Hachages dans lequel HashTab peut calculer les hashcodes, selon vos choix (paramétrables), dans 1 à plusieurs des 30 algorithmes qu'il sait utiliser (Adler32; Blake2sp; Btih; CRC-32; CRC-64; ED2K; Gost; Keccak-224; Keccak-256; Keccak-384; Keccak-512; MD2; MD4; MD5; Ripemd-128; Ripemd-160; Ripemd-256; Ripemd-320; SHA-1; SHA-256; SHA-256 base 64; SHA-384; SHA-512; SHA3-224; SHA3-256; SHA3-384; SHA3-512; TTH; Tiger; Whirlpool).

Explorateur Windows Clic droit sur le fichier dont on veut un condensat Propriétés Onglet Hachage Paramètres Dans la majorité des cas, cochez uniquement MD5, SHA-1, SHA-256.

Un algorithme de hachage est un algorithme qui génère une valeur, appelée hashcode ou condensat, courte, mais normalement unique, représentant la valeur d'origine (un mot de passe, le contenu d'un fichier, une clé de session, etc.). Avec un bon algorithme de hachage, la plus infime modification de la données en entrée entraîne la modification complète de la valeur de hachage résultante. Pour cette raison, les hachages sont utiles dans la détection des modifications apportées à une donnée, notamment un message. En outre, un bon algorithme de hachage rend impossible la construction, par calculs, de deux données distinctes qui donneraient le même hachage. Les algorithmes de hachage par défaut sont MD5, SHA-1 et SHA-256.

Depuis 2004 pour MD5 et 2012 pour SHA-1, ces deux algorithmes commençent à être en retrait (des collisions commencent à pouvoir être calculées à volonté pour MD5, dès 2004). L'usage de SHA-256, résistant aux attaques, s'impose lentement en remplacement des algorithmes faillibles.

Si on applique le même algorithme à une collection de données, des hashcodes différents doivent signifier que les données sont différentes. Par contre, si deux hashcodes sont identiques, il y a un risque (de fort à infime selon l'algorithme), que deux données soient différentes malgré tout.

Les anciens algorithmes comme CRC-16 ou CRC-32, classés par similitudes et facilités avec les algorithmes de hashage, n'en sont pas et servent à générer de simples clés de contrôle très souvent identiques (nommées « collisions ») pour des données différentes. Ils sont utilisés pour déceler une perte/erreur lors du transfert d'une donnée (trasfert de fichiers, etc.). Cette faiblesse de CRC-32 fut d'ailleurs la base du travail du chercheur Guillermito lorsqu'il écrivit son fameux article descendant en flamme l'antivirus sans base de signature Viguard : « Comment baiser Viguard ».

Exemples d'usages :

• Envoi d'un fichier dont on veut s'assurer la bonne transmission
  Celui qui envoie un fichier calcule le hashcode du fichier et envoie le fichier et son hashcode par un/des moyen(s) quelconque(s).
  Celui qui reçoit le fichier recalcule le hashcode du fichier reçu et compare le hashcode reçu avec celui recalculé par lui-même (avec le même algorithme). S'ils sont identiques, le fichier reçu est strictement identique à celui d'origine sinon il faut le renvoyer (ce qui se fait rapidement et automatiquement avec des algorithmes CRC).
  

• Gagner du temps et de la bande passante.
  Si un service en ligne vous demande de lui transmettre un fichier ou son hashcode, il est inutile d'occuper la bande passante et de perdre du temps à transmettre le fichier. Le temps de calcul de l'empreinte est négligeable par rapport au temps de transfert de la donnée elle-même, surtout si elle est volumineuse. Typiquement, le service d'analyses multi-antivirus VirusTotal (et tous les services multi-antivirus gratuits en ligne) permet de rechercher une analyse précédente par son hashcode (MD-5, SHA-1 ou SHA-256). Il est probablement inutile d'envoyer le fichier s'il a déjà été uploadé par quelqu'un d'autre : son hashcode suffit à l'identifier. Ce n'est que si le hashcode envoyé est inconnu qu'il faut envoyer le fichier lui-même.
  

La réputation de l'algorithme de calcul d'un hashcode (calcul d'un condensat - fonction de hachage) est de ne jamais produire deux hashcodes identiques si les objets (fichiers) contiennent la moindre différence. La fonction de hachage doit donc produire une clé unique d'identification d'une donnée unique (calcul homogène).

Réputation des fonctions de hachage

On voit souvent, en matière de sécurité informatique, principalement avec les services d'analyses antivirus, qu'il ne faut pas/plus identifier le contenu d'un fichier avec certaines fonctions de hachage (hashcodes, condensats, Empreinte cryptographique), dont les fonctions MD5 et SHA-1, car les créations de collisions, les attaques en force brute ou les utilisations de tables Arc-en-ciel permettent de casser l'unicité du condensat ou de remonter à son contenu crypté. Le tableau suivant, établi par les auteurs de Whirlpool (dernière version de ce tableau le 7 novembre 2017), donne l'état de l'art des principales fonctions de hachages et leurs poursuites de résistance ou leurs échecs aux attaques.

• (†) Par sa propre nature, FSB (Fast Syndrome-Based) est moins résistant à la recherche de collision que les attaques par le paradoxe des anniversaires. Pour cette raison, sa taille de résumé (condensat) doit toujours être supérieure à deux fois la sécurité de bit souhaitée.
  

• (‡) MAA est un code d'authentification de message (MAC - Message Authentication Code) plutôt qu'une fonction de hachage. Il a été inclus ici en raison de son importance dans le cadre de la norme ISO 8731-2.
  

Références

1.  [AB96] R. Anderson, E. Biham, "Tiger: A Fast New Hash Function", Fast Software Encryption -- FSE'96, LNCS 1039, Springer (1996), pp. 89--97.
2.  [AFS05] D. Augot, M. Finiasz, N. Sendrier, "A Family of Fast Syndrome Based Cryptographic Hash Functions", LNCS 3715, Springer (2005), pp. 64--83.
3.  [AR92] ISO N179, "AR Fingerprint Function", working document, ISO-IEC/JTC1/SC27/WG2, International Organization for Standardization, 1992.
4.  [BC04] E. Biham, R. Chen, "Near-Collisions of SHA-0", Advances in Cryptology -- Crypto'2004, LNCS 3152, Springer (2004), pp. 290--305. Updated version.
5.  [BDPvA06] G. Bertoni, J. Daemen, M. Peeters, G. van Assche, "RadioGatún, a belt-and-mill hash function", Second NIST Cryptographic Hash Workshop, Santa Barbara, USA, August 24--25, 2006.
6.  [BGG92] T. Baritaud, H. Gilbert, M. Girault, "F.F.T. hashing is not collision-free", Advances in Cryptology -- Eurocrypt'92, LNCS 658, Springer (1992), pp. 35--44.
7.  [BPSSS06] K. Bentahar, D. Page, J. H. Silverman, M.-J. O. Saarinen, N. P. Smart, "LASH", Second NIST Cryptographic Hash Workshop, Santa Barbara, USA, August 24--25, 2006.
8.  [BR00] P. S. L. M. Barreto, V. Rijmen, "The Whirlpool Hashing Function", First open NESSIE Workshop, Leuven, Belgium, November 13--14, 2000.
9.  [BRS02] J. Black, P. Rogaway, and T. Shrimpton, "Black-Box Analysis of the Block-Cipher-Based Hash-Function Constructions from PGV", Advances in Cryptology -- CRYPTO'2002, LNCS 2442, Springer (2002), pp. 320--335.
10.  [BS91] E. Biham and A. Shamir, "Differential cryptanalysis of Feal and N-Hash", Advances in Cryptology -- Eurocrypt'91, LNCS 547, Springer (1991), pp. 1-­16.
11.  [BS93] E. Biham and A. Shamir, "Differential Cryptanalysis of the Data Encryption Standard", Springer (1993).
12.  [CJ98] F. Chabaud and A. Joux, "Differential Collisions in SHA-0", Advances in Cryptology -- Crypto'98, LNCS 1462, Springer (1998), pp. 56--71.
13.  [D95] J. Daemen, " Cipher and Hash Function Design, Strategies Based on Linear and Differential Cryptanalysis", Doctoral dissertation, Katholiek Universiteit Leuven, 1995.
14.  [D89] I. B. Damgård, "A Design Principle for Hash Functions," Advances in Cryptology -- Crypto'89, LNCS 435, Springer (1989), pp. 416--427.
15.  [D96] H. Dobbertin, "The Status of MD5 after a Recent Attack", CryptoBytes2:2 (1996), pp. 1--6.
16.  [D97] H. Dobbertin, "RIPEMD with Two-Round Compress Function is Not Collision-Free", Journal of Cryptology10:1 (1997), pp. 51--70.
17.  [D98] H. Dobbertin, "Cryptanalysis of MD4", Journal of Cryptology11:4 (1998), pp. 253--271.
18.  [D02] J. Daemen, personal communication, 2002 (if you are curious, it merely states that Boognish is "certainly weak").
19.  [DBGV91] J. Daemen, A. Bosselaers, R. Govaerts, J. Vandewalle, "Collisions for Schnorr's Hash Function FFT-Hash", Advances in Cryptology -- Asiacrypt'91, LNCS 739, Springer (1993), pp. 447--480.
20.  [DBP96] H. Dobbertin, A. Bosselaers, and B. Preneel, "RIPEMD-160, a strengthened version of RIPEMD", Fast Software Encryption -- FSE'96, LNCS 1039, Springer (1996), pp. 71--82.
21.  [DC98] J. Daemen and C. Clapp, "Fast Hashing and Stream Encryption with PANAMA", Fast Software Encryption -- FSE'98, LNCS 1372, Springer (1998), pp. 60--74.
22.  [DGV91] J. Daemen, R. Govaerts, and J. Vandewalle, "A Framework for the Design of One-Way Hash Functions Including Cryptanalysis of Damgård's One-Way Function Based on Cellular Automata", Advances in Cryptology - Asiacrypt'91, LNCS 739, Springer (1993), pp. 82--96.
23.  [DGV92a] J. Daemen, R. Govaerts, and J. Vandewalle, "Fast Hashing Both in Hard- and Software", ESAT-COSIC Report92-2, Department of Electrical Engineering, Katholieke Universiteit Leuven, April 1992.
24.  [DGV92b] J. Daemen, R. Govaerts, and J. Vandewalle, "A Hardware Design Model for Cryptographic Algorithms", European Symposium on Research in Computer Security - ESORICS, 1992, pp. 419--434.
25.  [DK93] I. B. Damgård, and L. R. Knudsen, "The breaking of the AR Hash Function", Advances in Cryptology -- EUROCRYPT'93, LNCS 765, Springer (1994), pp. 286--292.
26.  [DV07] J. Daemen, G. van Assche, " Producing Collisions for Panama, Instantaneously, Fast Software Encryption -- FSE'2007, LNCS 4593, Springer (2007), pp. 1--18.
27.  [G94] Government Committee of Russia for Standards, "Information technology. Cryptographic Data Security. Hashing function.", GOST R 34.10-94, Gosudarstvennyi Standard of Russian Federation, 1994. See also " Using the GOST R 34.10-94, GOST R 34.10-2001 and GOST R 34.11-94 algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile, Serguei Leontiev, 2005.02.08.
28.  [GBR06] D. L. Gazzoni Filho, P. S. L. M. Barreto, V. Rijmen, "The Maelstrom-0 Hash Function", VI Brazilian Symposium on Information and Computer Systems Security -- SBSeg'2006.
29.  [GMDV06] P. Gauravaram, W. Millan, E. Dawson, K. Viswanathan, "Constructing Secure Hash Functions by Enhancing Merkle-Damgård Construction", Cryptology ePrint Archive, Report 2006/061.
30.  [HPR04] P. Hawkes, M. Paddon, G. G. Rose, "On Corrective Patterns for the SHA-2 Family", Cryptology ePrint Archive, Report 2004/207.
31.  [HS06] J. J. Hoch, A. Shamir, "Breaking the ICE - Finding Multicollisions in Iterated Concatenated and Expanded (ICE) Hash Functions", Fast Software Encryption -- FSE'2006, LNCS 4047, Springer (2006), pp 179--194. Preliminary version.
32.  [ISO88] ISO Standard 8731-2, 1988. More information can be found here.
33.  [J04] A. Joux, "Multicollisions in Iterated Hash Functions. Applications to Cascaded Constructions", Advances in Cryptology - Crypto'2004, LNCS 3152, Springer (2004), pp. 306--316.
34.  [JP05] C. S. Jutla and A. C. Patthak, "A Simple and Provably Good code for SHA Message Expansion", First NIST Cryptographic Hash Workshop, Gaithersburg, USA, October 31 -- November 01, 2005. Full version: C. S. Jutla and A. C. Patthak, "Provably Good Codes for Hash Function Design", Selected Areas in Cryptography - SAC'2006, LNCS , Springer (2007), to appear.
35.  [K92] B. Kaliski, "The MD2 Message-Digest Algorithm", RFC 1319 (1992).
36.  [KS05] J. Kelsey, B. Schneier, " Second Preimages on n-Bit Hash Functions for Much Less than 2ⁿ Work," Advances in Cryptology - Eurocrypt'2005, LNCS 3494, Springer (2005), pp. 474--490.
37.  [K05a] V. Klima, "Finding MD5 Collisions -- a Toy For a Notebook", Cryptology ePrint Archive, Report 2005/075.
38.  [K05b] V. Klima, "Finding MD5 Collisions on a Notebook PC Using Multi-message Modifications", Cryptology ePrint Archive, Report 2005/102.
39.  [K06] V. Klima, "Tunnels in Hash Functions: MD5 Collisions Within a Minute", Cryptology ePrint Archive, Report 2006/105.
40.  [K05] L. R. Knudsen, "SMASH - A Cryptographic Hash Function", Fast Software Encryption - FSE'2005, LNCS 3557, Springer (2005), pp. 228--242.
41.  [KBPL05] J. Kim, A. Biryukov, B. Preneel, S. Lee, "On the Security of Encryption Modes of MD4, MD5 and HAVAL", Cryptology ePrint Archive, report 2005/327.
42.  [KK06] T. Kohno, J. Kelsey, " Herding Hash Functions and the Nostradamus Attack", First NIST Cryptographic Hash Workshop, Gaithersburg, USA, October 31 -- November 01, 2005. Full version: Advances in Cryptology -- Eurocrypt'2006, LNCS 4004, Springer (2006), pp. 183--200.
43.  [KL06] J. Kelsey, S. Lucks, " Collisions and Near-Collisions for Reduced-Round Tiger", Full version: Fast Software Encryption -- FSE'2006, LNCS 4047, Springer (2006), pp. 111--125.
44.  [KP00] P. Kasselman, W. Penzhorn, "Cryptanalysis of Reduced Version of HAVAL", Electronics letters, Vol. 36, No. 1, January 2000, pp. 30--31.
45.  [L04] S. Lucks, "Design Principles for Iterated Hash Functions", Cryptology ePrint Archive, report 2004/253.
46.  [M89] R. C. Merkle, "One Way Hash Functions and DES", Advances in Cryptology - Crypto'89, LNCS 435, Springer (1989), pp. 428--446.
47.  [M90] R. C. Merkle, "A Fast Software One-Way Hash Function", Journal of Cryptology3:1 (1990), pp 43--58.
48.  [M04] F. Muller, " The MD2 Hash Function Is Not One-Way," Advances in Cryptology - Asiacrypt'2004, LNCS 3329, Springer (2004), pp. 214--229.
49.  [MOI90] S. Miyaguchi, K. Ohta, and M. Iwata, "128-bit hash function (N-hash)", NTT Review, vol. 2 (no. 6), Nov. 1990, pp. 128--132.
50.  [MPRYW06] F. Mendel, B. Preneel, V. Rijmen, H. Yoshida, D. Watanabe, "Update on Tiger", Progress in Cryptology -- INDOCRYPT'2006, LNCS 4329, Springer (2006), pp. 63--79.
51.  [MZ06] I. Mironov, L. Zhang, "Applications of SAT Solvers to Cryptanalysis of Hash Functions", Theory and Applications of Satisfiability Testing -- SAT 2006, LNCS 4121, Springer (2006), pp. 102--115.
52.  [NN91] NIST/NSA, "FIPS 180" (superseded by FIPS 180-1 and FIPS 180-2). See also NIST's Secure Hashing site.
53.  [NN02] NIST/NSA, "FIPS 180-2: Secure Hash Standard (SHS)", August 2002 (change notice: February 2004). See also NIST's Secure Hashing site.
54.  [PGV93] B. Preneel, R. Govaerts, J. Vandewalle, "Hash Functions Based on Block Ciphers: A Synthetic Approach", Advances in Cryptology - Crypto'93, LNCS 773, Springer (1990), pp. 368--378.
55.  [PRO97] B. Preneel, V. Rijmen, and P. van Oorschot, "Security analysis of the Message Authenticator Algorithm (MAA)", European Transactions on Telecommunications, Vol. 8, No. 5 (Sept./Oct. 1997), pp. 455--470.
56.  [PRR05] N. Pramstaller, C. Rechberger, V. Rijmen, "Smashing SMASH", Cryptology ePrint Archive, report 2005/081.
57.  [R90] R. L. Rivest, "The MD4 Message Digest Algorithm", Advances in Cryptology - Crypto'90, LNCS 537, Springer (1990), pp. 303--311.
58.  [R92] R. L. Rivest, "The MD5 Message Digest Algorithm", RFC 1321 (1992).
59.  [R04] V. Rijmen, "Update on SHA-1", Topics in Cryptography -- CT-RSA'2005, LNCS 3376, Springer (2005), pp. 58--71.
60.  [RC95] N. Rogier, P. Chauvaud, "The compression function of MD2 is not collision free", Selected Areas in Cryptography -- SAC'95, Ottawa, Canada, May 18--19, 1995 (workshop record).
61.  [RIPE92] Research and Development in Advanced Communication Technologies in Europe, "RIPE Integrity Primitives: Final Report of RACE Integriy Primitives Evaluation (R1040)", RACE, June 1992.
62.  [RRPV01] V. Rijmen, B. Van Rompay, B. Preneel, J. Vandewalle, "Producing Collisions for PANAMA", Fast Software Encryption - FSE'2001, LNCS 2355, Springer (2002), pp. 37--51.
63.  [RBPV03] B. Van Rompay, A. Biryukov, B. Preneel, J. Vandewalle, " Cryptanalysis of 3-pass HAVAL", Advances in Cryptology - Asiacrypt'2003, LNCS 2894, Springer (2003), pp. 228--245.
64.  [S91] C. Schnorr, "FFT-Hash, An Efficient Cryptographic Hash Function", Crypto'91 rump session, unpublished manuscript, 1991.
65.  [S92] C. Schnorr, "FFT-Hash II, efficient cryptographic hashing", Advances in Cryptology - Eurocrypt'92, LNCS 658, Springer (1992), pp. 45--54.
66.  [S06] M. Stevens, "Fast Collision Attack on MD5", Cryptology ePrint Archive, report 2006/104.
67.  [SV93] C. Schnorr, S. Vaudenay, "Parallel FFT-Hashing", Fast Software Encryption - FSE'93, LNCS 809, Springer (1994), pp. 149--156.
68.  [TTA05] Telecommunications Technology Association, "TTAS.KO-12.0011/R2: Hash Function Standard - Part 2: Hash Function Algorithm Standard (HAS-160)", December 2005.
69.  [V92] S. Vaudenay, "FFT-Hash-II is not yet Collision-free", Advances in Cryptology - Crypto'92, LNCS 740, Springer (1993), pp. 587--593.
70.  [WFLY04] X. Wang, D. Feng, X. Lai, H. Yu, "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", Cryptology ePrint Archive, Report 2004/199.
71.  [WLFCY05] X. Wang, X. Lai, D. Feng, H. Chen, X. Yu, " Cryptanalysis of the Hash Functions MD4 and RIPEMD", Advances in Cryptology -- Eurocrypt'2005, LNCS 3494, Springer (2005), pp. 1--18.
72.  [WY05] X. Wang, H. Yu, " How to Break MD5 and Other Hash Functions", Advances in Cryptology -- Eurocrypt'2005, LNCS 3494, Springer (2005), pp. 19--35.
73.  [WYY05] X. Wang, Y. L. Yin, H. Yu, "Collision Search Attacks on SHA1", research summary, 2005.
74.  [ZPS92] Y. Zheng, J. Pieprzyk, and J. Seberry, "HAVAL - a one-way hashing algorithm with variable length of output", Advances in Cryptology - Auscrypt'92, LNCS 718, Springer (1993), pp. 83--104.

Un des usages de la cryptographie permise avec les hashcodes est de partir d'une donnée unique, quelle que soit sa taille, et d'en calculer un hashcode (condensat) tout aussi unique.

Exemples :

• Soit la phrase : Papa aime Maman
  

• Son « hashcode », selon l'algorithme MD5, est : 99685cdcbee4ac3fc7934da83b703a10
  

Si l'on modifie le moindre caractère de la phrase d'origine, on obtiendra un hashcode totalement différent.

Mettons un A majuscule à aime :

• Soit la phrase : Papa Aime Maman.
  

• Son « hashcode », selon l'algorithme MD5, devient : eebe99faedaa305eb8c8799b2c7ba97a

Ajoutons un point final à la phrase :

• Soit la phrase : Papa aime Maman.
  

• Son « hashcode », selon l'algorithme MD5, devient : da6d8d582d8440619b278dbd324d3596

Un « hashcode » est une valeur calculée par un algorithme de hachage (les plus universellement utilisés sont CRC16, CRC32, NTLM, MD5, SHA-1, SHA-2, SHA-256) appliqué à une donnée (contenu d'un fichier, chaîne de caractères comme un « mot de passe », etc.), uniquement la donnée et toute la donnée. Peu importe le nom du contenant (s'il y en a un - nom du fichier...), ses attributs, ses dates prétendues de création ou de dernière modification, etc. qui sont toutes des données externes à la donnée elle-même (elles forment l'enveloppe dont on ne doit pas tenir compte - on ne tient compte que du contenu).

La réputation de l'algorithme de calcul d'un hashcode est de ne jamais produire deux hashcodes identiques si les objets (fichiers) contiennent la moindre différence. La fonction de hachage doit donc produire une clé unique d'identification d'une donnée unique (c'est le calcul homogène).

L'intérêt des « hashcodes » est triple :

1. Intégrité des données
   Il est impossible de modifier la donnée (injection d'une malveillance, tel un virus, modification d'un seul bit ou, tout simplement, nouvelle version de la donnée...) en lui conservant un même « hashcode ». Par exemple : un fichier est proposé en téléchargement et son « hashcode » est affiché sur le site proposant ce fichier (c'est le cas chez Assiste.com). Une fois le fichier réceptionné, vous utilisez HashTab pour recalculer ce « hashcode » avec le même algorithme MD5 ou SHA-1. Si les deux « hashcodes » sont identiques, le fichier réceptionné est strictement le même que celui d'origine. C'est le principe du « Contrôle d'intégrité des données » (qui ne doit pas être confondu avec l'innocuité des données - vous pouvez seulement vous assurer que le téléchargement s'est bien passé, rien d'autre - si le fichier téléchargé est un virus, vous vérifiez ainsi que vous avez reçu un virus en parfait état ! Faites analyser gratuitement et immédiatement le fichier réceptionné par plus de 70 antivirus simultanés, avec le service VirusTotal ou tout autres services multiantivirus gratuits en ligne, avant de l'exécuter (avant de l'ouvrir) !

2. Calcul à sens unique (théoriquement)
   Il n'est, théoriquement, pas possible de faire le calcul inverse : de remonter d'un hashcode à la chaîne de caractères d'origine (il n'est pas possible (théoriquement) de retrouver la chaîne de caractres d'origine à partir de son hashcode). Voir, dans les techniques d'attaques des mots de passe, que ce vœu pieux est battu en brèche.

3. Unicité du chiffre clé
   De purs travaux de laboratoire ont permis la création de « hashcodes » identiques (appelés « collisions ») à partir de données différentes. Ce risque est total avec les algorithmes antédiluviens et abandonnés comme CRC-16 et CRC-32. Ce risque existe avec les algorithmes MD5 depuis 2004 et SHA-1 depuis 2012 avec lesquels il est désormais possible de créer des « collisions ». Pour prendre un peu d'avance sur les futurs développements matériels et logiciels des cybercriminels, on recommande désormais le calcul des hashcodes avec SHA-256.

Lorsque vous créez un « mot de passe » pour protéger l'accès à une ressource (votre ordinateur, un fichier, un compte sur un site ou un forum, un panneau de gestion d'un compte en banque d'entreprise ou de particulier, un document secret d'un chercheur, d'un journaliste, d'un avocat..., les correspondances d'un diplomate ou d'un homme politique etc.), le « mot de passe » n'est pas (normalement) stocké en clair. Le « site de confiance » le crypte, sous forme d'un « hashcode », le plus souvent avec l'algorithme MD5 ou SHA-1, et stocke uniquement votre identifiant et le « hashcode », mais ne stocke pas en clair le mot de passe lui-même.

Lorsque vous revenez vous identifier pour utiliser cette ressource protégée, vous saisissez (composez) à nouveau votre identifiant (login) et votre « mot de passe ». Le site refait un calcul de « hashcode » avec le même algorithme.

Le site compare alors le « hashcode » du mot de passe de référence à celui qui vient d'être calculé. Si les deux sont identiques, c'est que les deux « mots de passe » sont identiques. L'autorité vous donne alors accès à la ressource, sinon elle vous en interdit l'accès.

• Note 1
  D'où l'intérêt des logiciels en « Open Source » où l'on peut voir comment sont traités les données sensibles tandis qu'on ne peut qu'avoir des soupçons de malveillances avec les logiciels « propriétaire » et les sites pour lesquels aucune confiance ne peut être accordée (comme tous les réseaux sociaux, les éditeurs de logiciels proches de leurs gouvernements, les nébuleuses du « Cloud Computing » etc. ...)
  
  

• Note 2
  C'est la raison pour laquelle, lorsque vous perdez votre « mot de passe », il n'est pas possible de le retrouver car, s'il est possible de calculer un MD5 ou un SHA-1 à partir d'un « mot de passe », il n'est théoriquement pas possible de retrouver (recalculer) le « mot de passe » d'origine à partir de son MD5 ou de son SHA-1.
  
  

• Note 3
  Il serait préférable que, lors de la saisie de votre mot de passe, la communication entre votre ordinateur et celui du site distant se fasse dans un protocole de communication sécurisé (HTTPS), sinon une attaque par « sniffer » lira vos mots de passe en clair, avant qu'ils ne soient cryptés. Regardez en bas à droite de votre navigateur si un cadenas fermé apparaît. Mais le protocoleHTTPS ne sera mis en œuvre que par des sites professionnels. Ce ne sera pas le cas des millions de forums, blogs etc. ... sur lesquels il faut également s'identifier (d'où l'intérêt d'utiliser des mots de passe différents).
  
  

• Note 4
  Certains sites Internet usurpent l'apparence de sites ayant pignon sur rue est utilisent des URL trompeuses. Sur de tels sites de « phishing », vers lesquels vous êtes souvent dirigés depuis un e-mail trompeur, vos identifiant et mot de passe sont stockés en clair et exploités immédiatement par des cybercriminels. Et absolument rien ne permet d'être certain de ce que font les très grands sites à la solde des gouvernements, comme Microsoft (Microsoft vous espionne) ou Google (Google vous espionne).
  

Les outils les plus simples de calcul de hashcodes, et de très loin, sont ceux qui s'installent en tant que « propriété » additionnelle d'un fichier dans l'explorateur de fichiers de Windows.

1. SummerProperties
   SummerProperties ajoute un onglet « CheckSums » aux propriétés d'un fichier, dans l'explorateur de fichiers de Windows, et propose 4 algorithmes de hashcodes : CRC-16, CRC-32, MD5 et SHA-1.
   SummerProperties est gratuit, mais, bien qu'encore fonctionnels, les algorithmes qu'il propose ne sont plus suffisants :

   • CRC-16 et CRC-32 n'ont aucun intérêt et ne sont pas de véritables algorithmes de hachage, mais des « Contrôle de Redondance Cyclique ». On peut les oublier.

   • Des collisions peuvent être forgées à la demande contre les hachages MD5 et SHA-1.

   On laisse tomber SummerProperties.

   Voir SummerProperties.

2. HashTab
   HashTab ajoute un onglet « Hachages » aux propriétés d'un fichier, dans l'explorateur de fichiers de Windows, et propose 30 algorithmes de hashcodes : (Adler32; Blake2sp; Btih; CRC-32; CRC-64; ED2K; Gost; Keccak-224; Keccak-256; Keccak-384; Keccak-512; MD2; MD4; MD5; Ripemd-128; Ripemd-160; Ripemd-256; Ripemd-320; SHA-1; SHA-256; SHA-256 base 64; SHA-384; SHA-512; SHA3-224; SHA3-256; SHA3-384; SHA3-512; TTH; Tiger; Whirlpool). Ce produit est gratuit.

   Voir HashTab.

3. VT Hash Check (VirusTotal Hash Check)
   VT Hash Check ajoute une propriété (sous le nom de Check File Hash) aux fichiers, dans l'explorateur de fichiers de Windows. VT Hash Check calcule un hashcode d'un fichier désigné par l'utilisateur, selon l'algorithme choisi parmi les 3 proposés (MD5, SHA-1, SHA-256 [recommandé]) et soumet instantanément ce hashcode au service multiantivirus gratuit en ligne VirusTotal(70 antivirus simultanés en juillet 2020).

   Vous êtes vivement incités à installer VT Hash Check (gratuit; sous Windows).

   Voir VT Hash Check (VirusTotal Hash Check).