Plusieurs mécanismes produisent de courtes valeurs qui semblent vérifier des données. Ils ne donnent pourtant pas les mêmes garanties. Un checksum détecte des erreurs accidentelles. Un hash cryptographique crée une empreinte forte. Un MAC prouve qu’un message vient de quelqu’un qui possède un secret partagé. Une signature numérique permet la vérification publique avec une clé. Le bon choix commence par la menace.
Les checksums détectent les accidents
CRC32 et mécanismes proches sont rapides et compacts. Ils détectent des corruptions de transmission ou de stockage dans un contexte non adversarial. Ils ne résistent pas à un attaquant capable de modifier données et checksum.
Utilisez-les pour les erreurs ordinaires. Ne les présentez pas comme une sécurité de téléchargement ou de mise à jour.
Les hashes cryptographiques donnent une empreinte forte
Un hash moderne comme SHA-256 rend impraticable la construction de collisions utiles. Il identifie un contenu et détecte des changements. Mais n’importe qui peut calculer un nouveau hash pour un contenu modifié.
L’empreinte attendue doit venir d’un canal fiable ou être signée. La publier à côté du fichier sur le même serveur compromis ne suffit pas.
Un MAC authentifie avec un secret partagé
Un message authentication code combine message et clé secrète. HMAC est une construction courante. Le destinataire qui possède le même secret vérifie que le message vient d’une partie ayant ce secret et n’a pas été modifié.
Comme les deux parties partagent la clé, les deux peuvent créer des messages valides. C’est adapté entre services de confiance, moins pour prouver à un tiers qui a signé.
La signature sépare signer et vérifier
Une signature numérique utilise une clé privée pour signer et une clé publique pour vérifier. Beaucoup de destinataires peuvent vérifier un release ou document sans pouvoir produire une signature. Cette asymétrie soutient certificats, distribution logicielle et audit public.
La confiance se déplace vers la propriété de la clé publique. Une signature valide n’aide que si cette clé appartient réellement au signataire attendu.
Les données structurées demandent canonicalisation
Ces outils opèrent sur des bytes exacts. Deux JSON équivalents avec ordre de propriétés différent ont des hashes différents. Les protocoles qui signent des documents structurés doivent définir une représentation canonique ou préserver les bytes originaux.
Une normalisation artisanale peut devenir vulnérable si le signataire et le vérificateur interprètent différemment le même texte.
Le nom d’algorithme ne suffit pas
“Nous utilisons SHA-256” ne dit pas si l’on calcule un hash, un HMAC, une dérivation de mot de passe ou une signature. La gestion des clés, la représentation, la comparaison et la réaction aux erreurs déterminent la sécurité réelle.
Évitez les combinaisons maison de secrets et messages. Les bibliothèques maintenues fournissent des constructions revues.
Les clés ont un cycle de vie
MAC et signatures nécessitent identifiants de clé, rotation et règles de vérification des artefacts anciens. Supprimer une ancienne clé publique peut rendre des documents légitimes impossibles à vérifier.
Les clés privées doivent être protégées et auditées. Les secrets partagés compliquent l’attribution, car chaque détenteur peut créer un message valide.
Les couches peuvent se compléter
Un pipeline peut utiliser CRC pour une corruption rapide, hash de contenu pour déduplication et signature pour authenticité. Ce n’est pas redondant si chaque couche répond à une question différente.
La documentation devrait dire quelle question chaque valeur répond et quoi faire en cas d’échec. Sans cela, un futur changement peut conserver le champ mais perdre la garantie.
La fréquence d’usage influence le choix
Un checksum dans un paquet réseau doit être extrêmement rapide. Une signature de release peut être plus coûteuse parce qu’elle se vérifie moins souvent et protège davantage. Un MAC entre services doit équilibrer latence et sécurité. Le bon mécanisme dépend aussi de l’endroit où il s’exécute.
Cette analyse évite d’utiliser un outil fort au mauvais endroit ou un outil rapide pour une menace adversariale.
La rotation de clés doit préserver les archives
Les signatures anciennes doivent rester vérifiables lorsque c’est nécessaire. Supprimer sans plan les clés publiques historiques casse audits et preuves. À l’inverse, garder une clé compromise active trop longtemps augmente le risque. Le lifecycle doit être écrit.
Les valeurs doivent porter un identifiant d’algorithme ou de clé lorsque plusieurs options existent. Sans metadata, le vérificateur doit deviner et finit souvent par accepter trop de cas pour rester compatible.
Le refus doit arrêter l’action dangereuse
Si la signature d’une mise à jour échoue, l’installation ne doit pas continuer parce que le réseau semble instable. Fail-open supprime la protection au moment critique. Le diagnostic doit être précis: clé inconnue, bytes modifiés, signature invalide ou certificat expiré.
Les chemins de secours doivent être testés comme le chemin nominal. Une dépendance de vérification indisponible ne devrait pas transformer automatiquement un contrôle fort en simple avertissement.
Checksum, hash, MAC et signature se ressemblent visuellement, mais leurs promesses sont différentes. Nommer la menace rend le choix beaucoup plus simple.