Générer un hash

Non. Le fichier est haché avec la même cryptographie intégrée que celle qui gère le HTTPS. Rien n'est conservé : il n'y a donc ni plafond de taille, ni attente liée à la connexion.

La mémoire disponible, pas un plafond fixe. La cryptographie du navigateur ne sait pas hacher un fichier par morceaux — elle a besoin du fichier entier en mémoire d'un coup — si bien qu'un très gros fichier (une image de DVD, par exemple) peut échouer sur une machine incapable de le contenir. Les fichiers jusqu'à quelques centaines de mégaoctets passent sans problème sur un ordinateur ordinaire. Si un gros fichier échoue, c'est cette limite que vous avez atteinte, et la page vous le dit au lieu de rester bloquée.

SHA-256 pour tout nouvel usage. C'est la norme actuelle, celle qu'utilisent les sommes de contrôle de logiciels, les empreintes de conteneurs et les blockchains, et on ne lui connaît aucune faiblesse. N'utilisez MD5 ou SHA-1 que lorsque quelque chose d'autre les exige — une ancienne somme publiée, un système hérité, ou Git, qui identifie les objets par SHA-1. Utilisez SHA-512 quand vous voulez précisément une empreinte plus longue ; sur les machines 64 bits, il est souvent plus rapide que SHA-256, pas plus lent.

Vous le pouvez, mais vous ne devez pas stocker le résultat. C'est l'erreur la plus répandue dans ce domaine, alors disons-le franchement : MD5, SHA-1 et SHA-256 sont tous inadaptés aux mots de passe, et la robustesse cryptographique de SHA-256 n'y change rien. Le problème, c'est que ces fonctions sont RAPIDES par conception — une carte graphique moderne calcule des milliards de hashs SHA-256 par seconde, si bien qu'une base volée de mots de passe hachés en SHA-256 se casse à une vitesse phénoménale. Les mots de passe exigent une fonction délibérément lente et salée, conçue pour cet usage : bcrypt, scrypt ou Argon2. Tout framework sérieux en intègre une.

Parce que n'importe qui peut désormais fabriquer deux fichiers différents ayant le même hash MD5, sur du matériel ordinaire, en quelques secondes. C'est vrai depuis 2004, et cela a été démontré avec des conséquences bien réelles — deux PDF présentant des contrats différents, deux exécutables dont l'un est un logiciel malveillant. MD5 ne peut donc pas prouver qu'un fichier est bien celui que vous attendiez ; une falsification délibérée peut correspondre. Il reste tout à fait valable pour détecter une corruption accidentelle, comme un téléchargement défectueux ou une copie tronquée, ce à quoi servent en réalité la plupart des sommes MD5 publiées. Il ne doit jamais être utilisé pour la sécurité.

Pour la même raison, plus récemment. En 2017, Google et le CWI ont produit deux PDF différents ayant le même hash SHA-1, et dès 2020 l'attaque était assez bon marché pour falsifier des signatures. Les navigateurs ont cessé d'accepter les certificats SHA-1 il y a des années, et Git est en train de l'abandonner. Si vous choisissez un algorithme aujourd'hui, choisissez SHA-256.

Déposez le fichier téléchargé, puis collez dans la zone de comparaison la somme de contrôle du site d'où il provient. Si elles correspondent, le fichier est arrivé intact et c'est bien celui qui a été publié. Sinon, supprimez-le et téléchargez-le à nouveau. Deux précautions : récupérez la somme de contrôle à la source officielle plutôt qu'à l'endroit où vous avez obtenu le fichier, et gardez en tête qu'une somme de contrôle prouve seulement que le fichier correspond à ce que cette page a publié — si la page elle-même a été compromise, les deux correspondront.

SHA-1, SHA-256, SHA-384 et SHA-512 proviennent de l'implémentation Web Crypto du navigateur, le même code que celui qui gère le HTTPS. MD5 ne fait pas partie de Web Crypto — délibérément, puisqu'il est cassé — il est donc implémenté ici directement d'après la RFC 1321 et vérifié avec les vecteurs de test publiés dans ce même document.