Le 12 janvier 2013 18:07, Nolwenn <donolw...@gmail.com> a écrit : > Tu devrais lire > https://fr.wikipedia.org/wiki/Somme_de_contr%C3%B4le#Somme_MD5 > pour mieux comprendre ce que j'ai écris au lieu de t'empresser de nous > balancer ta logorrhée habituelle. >
En plus tu cites en référence un bout de paragraphe minuscule de Wikipédia qui n'est pas une source et même ces deux lignes sont fausses aujourd'hui, MD5 n'est PAS utilisé par code.google.com pour verifier les signatures de fichiers (code.google.com utilise SHA1 justement, mais pas MD5 !) L'assertion qui consiste à dire que MD5 est de plus en plus populaire est totalement fausse. Bref ce paragraphe de l'article Wikipédia est totalement inutile et n'apporte strictement rien. Je vois donc que tu lis des trucs sans les évaluer ou juger de leur pertinence ou leur actualité. MD5 n'est plus recommandé depuis plusieurs années, SHA1 l'est encore de façon limitée mais plus pour les signatures authentiques (contre les falsifications volontaires, il y a des tonnes de fichiers virussés qui valident leur signature MD5 et même un grand nombre qui valident leur signature SHA1). La recommandation aujourd'hui c'est plutôt SHA256 (ou sa version tronquée SHA128), et pour les signatures authentiques de code c'est SHA512 (ou sa version tronquée SHA384). Pour les signatures authentique des pilotes Windows, Microsoft exige maintenant des clés de 1024 bits depuis le mois dernier et rejette les certificats signés avec des clés plus courtes depuis le début de ce mois de janvier. Alors ton MD5 est vraiment d'un autre âge... L'algo a plus de 30 ans et s'il ne résiste pas aux craqueurs volontaires, on a montré aussi qu'il comportait un trop grand nombre de collisions permettant des transmissions en apparence sans erreurs (c'est bien pour ça que Google n'en veut plus pour signer les fichiers compilés installables téléchargés sur code.google.com). L'outil md5sum proposé par l'article Wikipedia ne sert plus à rien, sauf pour des raisons historiques si on n'a pas d'autre clé disponible pour comparer. Il ne fait même plus partie de l'installation par défaut de bon nombre de distribs Linux (l'algo a même été interdit dans certaines administrations et dans toutes les applications de transaction sécurisées en ligne, notamment pour les banques; les navigateurs web et les PKI le rejettent maintenant tous comme invalides pour n'importe quel certificat ; il n'est plus utilisé non plus pour hasher de façon irréversible les mots de passes stockés dans /etc/passwd, sauf sur de très vielles installations qui devraient toutes avoir été mises à jour pour exiger de remplacer ces mots de passe obsolètes et facilement craquables). Les protocoles de communication n'ont jamais utilisé MD5 pour vérifier les transferts, même chose pour les systèmes de stockage (cela a toujours été des algos à redondance cyclique, réversibles pour permettre des corrections automatiques de certains types d'erreurs classiques des systèmes de transmission, tels que des bits inversés, ou écrasés sur des séquences courtes par du bruit impulsionnel, la réversibilité étant aussi leur défaut car ils sont facilement craquables même si on sait avec une clé courte limiter le nombre de collisions de clés identiques. Des protocoles plus récents n'utilisent plus les CRC mais des congruences dans des espaces linéaires bien plus complexes (cas du codage DSL, et des transmissions par satellite, mais aussi le cas sur les réseaux mobiles actuels). Les CRC ne servent plus que pour vérifier des messages très courts (un seul datagramme, ou une seule trame IP limitée à environ 1,5ko, ou 12 kbits : on est très en dessous de la taille des fichiers exécutables téléchargés et même de la plupart des contenus actuels du web : pages, scripts, images, audio et vidéo). Les formats modernes d'archives n'utilisent plus MD5 mais SHA1 (il reste le vieux CRC du format ZIP d'origine, mais comme il n'est plus sur on adjoint dans l'archive un fichier "manifeste" contenant des clés calculées avec des algos plus surs, généralement SHA1 ou SHA128). Pour signer une iamge de CD ou DVD ou BDROM, on utilise systématiquement SHA384 au moins et on signe les fichiers individuels d'une archive et de moins de 1Mo dans un manifeste avec SHA1. au delà c'est encore SHA384 ou plus pour tous les fichiers binaires exécutables (Google y viendra aussi sur les téléchargements qu'il propose sur code.google.com, car SHA1 n'est plus accepté partout comme suffisant : il est refusé maintenant dans l'administration américaine là où les normes FIPS s'imposent). Il y a encore d'autres bons alogos de hachage disponibles en remplacement de la série SHA*, un des meilleurs candidats (contre lequel on n'a encore rien trouvé, contrairement à SHA1 qui commence à craquer), c'est l'algo "Whirlpool", un autre algo candidat était "Tiger" mais il est aussi partiellement cassé et ne se différencie plus de SHA1 en terme de sécurité, il semble que Tiger tiendra encore moins longtemps que SHA1 (qui a l'avantage d'être plus facile et rapide à calculer et donc de ne pas trop faire souffrir les performances). Les implémentations de la série SHA* sont aussi natives (et plus ou moins parallélisables en partie) dans bon nombre de processeurs séquentiels ou de traitement du signal, contrairement à MD5 (MD4 est encore plus vieux et ne doit absolument pas être utilisé, on le casse en moins d'une seconde). Tiger est difficile à implanter à bas coût dans du matériel, il ne convient pas par exemple aux puces des cartes bancaires qui ont des processeurs de capacité limitée, alors que ces puces ont ce qu'il faut pour calculer les clés SHA*, même la plus longue SHA512, et de quoi ausi calculer les cryptages symétriques de la famille RSA basés sur une clé publique formée par le produit de deux nombres premiers dans un espace linéaire à congruence, ou des algos utilisant des espaces transformés curvilignes, le plus souvent elliptiquesn, ou des codages basés sur une transformée de Fourier, ou encore les vaguelettes, les distributions de Dirac ; la série RSA dépend d'un problème réputé complexe des algos de la famille "NP-complets", ici la factorisation d'un produit du produit de deux grands nombres premiers ; ces algos garantissent l'existence d'une longueur minimale de résistance voisine de la moitié de la longueur de la clé, une longueur encore divisée par deux encore par le paradoxe de l'anniversaire en tenant compte du hasard, ce qui fait qu'une clé de 1024 bits calculée par un algo NP-complet a une résistance garantie de 256 bits au minimum ; le seul actuel de résistance est aujourd'hui de l'ordre de 64 à 100 bits et on comprend pourquoi les clés publiques de certificats de signature demandent maintenant 1024 bits ; ce qui met en péril tous les algos NP-complet c'est la découverte d'attaques comparable à celle du paradoxe de l'anniversaire, les plus récentes ayant été celles basées sur le "timing" de réponse).
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
