Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    4 837
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 4 837
    Points : 125 602
    Points
    125 602
    Par défaut Arrêtez d'utiliser SHA-1 ! Des chercheurs affirment être parvenus à casser l'algorithme de hachage
    Arrêtez d'utiliser SHA-1 ! Des chercheurs affirment être parvenus à casser l'algorithme de hachage,
    et recommandent de passer à des versions plus sécurisées

    En 1995, SHA-1 (Secure Hash Algorithm), l’algorithme de hachage cryptographique conçu par la NSA, a été publié par le gouvernement des États-Unis comme standard fédéral de traitement de l'information. SHA-1 venait remplacer SHA-0 qui a été rapidement mis de côté par le NIST (Institut national des normes et de la technologie, une agence du département du Commerce des États-Unis) pour des raisons de sécurité insuffisante.

    Néanmoins, avec les années, SHA-1 n’a plus été considéré comme sûr face à des adversaires disposant de moyens importants, c’est ce qu’ont suggéré des cryptanalystes qui se sont penchés sur des attaques théoriques. Aussi, l’institut américain des standards avait déclaré SHA-1 obsolète en 2011. Il n’en a pas fallu beaucoup plus aux principaux navigateurs pour se décider à déprécier cet algorithme : Microsoft, Google et Mozilla ont annoncé la fin du support de SHA-1 sur leurs produits respectifs.

    De la théorie à la pratique

    En 2012, des cryptographes ont estimé qu'une attaque pratique contre SHA-1 pourrait coûter 700 000 dollars en utilisant les services de cloud computing en 2015 et 173 000 dollars en 2018. Cependant, en 2015, un groupe de chercheurs de Centrum Wiskunde et Informatica (CWI) aux Pays-Bas, Nanyang Technological University (NTU) à Singapour et INRIA en France ont conçu une nouvelle façon de briser le SHA-1 qui, selon eux, réduirait considérablement le coût des attaques.

    Depuis lors, les chercheurs de l'ICA ont travaillé avec Google, en utilisant l'infrastructure cloud de l'entreprise ainsi que son expertise technique pour réaliser une collision pratique.

    « Aujourd'hui, plus de 20 ans après que SHA-1 a été présenté pour la première fois, nous annonçons la première technique pratique pour générer une collision. Cela représente le point culminant de deux années de recherche issues d'une collaboration entre le CWI Institute d'Amsterdam et Google », a annoncé Google sur un billet.

    L’objectif de cette démarche était de souligner à quel point il est impérieux d’abandonner cet algorithme, dans un contexte où les machines sont de plus en plus puissantes, et de passer à des algorithmes plus sécurisés comme SHA-256 et SHA-3. Aussi, les chercheurs ont réalisé la toute première collision cryptographique de hachage sur SHA-1.

    La collision cryptographique de hachage, qu’est-ce que c’est ?

    L’une des propriétés des fonctions cryptographiques est le fait qu’elles sont unidirectionnelles ; en clair, il n’est pas possible de retrouver la chaîne originelle à partir du hash. Une seconde est que, théoriquement, deux chaînes de caractères différentes donneront systématiquement deux hash différents. C’est cette théorie que les chercheurs sont parvenus à démentir.

    Google explique qu’une collision se produit lorsque deux morceaux de données distinctes (un document, un binaire ou un certificat de site Web) figurent dans la même signature (voir le schéma ci-dessous). Comme expliqué plus haut, les collisions ne devraient jamais se produire pour des fonctions de hachage sécurisées. Cependant, si l'algorithme de hachage a quelques défauts, comme SHA-1, un attaquant bien équipé peut créer une collision. L'attaquant pourrait alors utiliser cette collision pour tromper les systèmes qui s'appuient sur les hachages et leur faire accepter un fichier malveillant à la place de son équivalent bénin. Par exemple, deux contrats d'assurance avec des termes radicalement différents. Les attaquants pourraient également créer une mise à jour logicielle frauduleuse, qui serait acceptée et exécutée par un mécanisme de mise à jour qui valide les mises à jour en vérifiant les signatures numériques.


    Pour leur attaque, les chercheurs ont produit deux fichiers PDF différents avec la même signature SHA-1.« En 2013, Marc Stevens a publié un article qui décrit une approche théorique pour créer une collision SHA-1. Nous avons commencé par créer un préfixe PDF spécifiquement conçu pour nous permettre de générer deux documents avec des contenus visuels distincts arbitraires, mais qui aurait un même hachage SHA-1 », ont expliqué les chercheurs.

    Cependant, ils ont dû faire face à un défi de taille : la puissance de calcul. Google s’est appuyé sur son expertise technique et son infrastructure cloud pour lancer une collision « qui est l’un des plus gros calculs jamais faits ». Voici quelques chiffres que Google a partagés : au total, neuf quintillions (9 223 372 036 854 775 808) de calculs SHA-1, 6 500 ans de calcul CPU pour compléter la première phase de l'attaque et 110 ans de calcul GPU pour compléter la deuxième phase.

    Source : blog Google

    Voir aussi :

    Google annonce la fin du support de SHA-1 dans Chrome, la firme accélère la mort de l'algorithme de hachage cryptographique

    SHA-1 : Microsoft suit l'exemple de Mozilla et opte pour une fin de support en juin 2016, au lieu de janvier 2017 sur son navigateur
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    août 2008
    Messages
    24 980
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 24 980
    Points : 176 288
    Points
    176 288
    Par défaut
    Cela fait un certain nombre d'années qu'on recommande de se passer de SHA-1 et d'utiliser quelque chose de plus sérieux, au moins SHA-2 (la première attaque théorique contre SHA-1 date de 2005, où on avait estimé que la fonction devrait être rapidement remplacée). Pour le moment, on ne connaît pas vraiment de faiblesse pour SHA-2 ou 3 : par défaut, tout le monde devrait les utiliser… En tout cas pour des applications cryptographiques.
    Vous souhaitez participer aux rubriques Qt ou PyQt (tutoriels, FAQ, traductions), HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  3. #3
    Nouveau Candidat au Club Avatar de Heliogabale
    Profil pro
    Inscrit en
    mai 2008
    Messages
    54
    Détails du profil
    Informations personnelles :
    Localisation : France, Savoie (Rhône Alpes)

    Informations forums :
    Inscription : mai 2008
    Messages : 54
    Points : 0
    Points
    0
    Par défaut
    La terreur est sur nous, donc.

    Si on continuait à tout mettre dans le nuage, et par la même pourrir la planète un peu plus et permettre aux GROS d'exploiter nos données sans permission ?

  4. #4
    Membre régulier
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2012
    Messages
    38
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : avril 2012
    Messages : 38
    Points : 100
    Points
    100
    Par défaut
    Citation Envoyé par Stéphane le calme Voir le message
    L’une des propriétés des fonctions cryptographiques est le fait qu’elles sont unidirectionnelles ; en clair, il n’est pas possible de retrouver la chaîne originelle à partir du hash. Une seconde est que, théoriquement, deux chaînes de caractères différentes donneront systématiquement deux hash différents. C’est cette théorie que les chercheurs sont parvenus à démentir.
    Je ne suis pas sûr que ce soit vrai, du moins pas si on veut avoir un hash dont la longueur peut être inférieur à celle de la chaine originelle que la chaine originelle.
    Par exemple si on utilise des hashes Bcrypt de 184 bits pour hasher des documents qui peuvent faire plusieurs ko, il y aura théoriquement toujours un risque de collision... simplement plus l’algorithme de hashage est gourmand en calcul plus il faudra de temps pour réussir à trouver une collision.

    De ce que je comprends les gars de chez Google n'ont pas démontré qu'il y avait un risque de collision avec SHA-1 (on le savait déjà), mais qu'il était techniquement possible de trouver une de ces collision de son vivant avec du matériel existant.

  5. #5
    MikeRowSoft
    Invité(e)
    Par défaut
    Citation Envoyé par BlueScreenJunky Voir le message
    simplement plus l’algorithme de hashage est gourmand en calcul plus il faudra de temps pour réussir à trouver une collision.
    De la construire n'est pas exclus.
    Il y a bien des 'hypothèses de départ', un début, ' "un traitement" ', "une fin".


    BitTorrent par exemple, il y a des verrous pour l'éviter ? Je suppose que non. De là a changer l'extension d'un fichier valide par une autre qui conserve la validité, il faut pas trop s'y attendre de si tôt. (i)

    PS: validité = exploitable via des applications de type de traitements différents.

    Citation Envoyé par Stéphane le calme Voir le message
    En 1995, SHA-1 (Secure Hash Algorithm), l’algorithme de hachage cryptographique conçu par la NSA[...]
    Eviter de toucher directement aux preuves, plus simple de les fabriquer et de chercher le plus plausible.

    (i) j'ai fais un drôle de rêve hier soir, celui de deux applications et du même fichier qui toucher depuis l'un interagi sur l'interprétation de l'autre, mais comme ils sont afficher sur la même interface une même t'utilisateur peut ainsi avoir un fichier, deux application et deux interprétation du même "CRC" ou SHA-1 ou autres...
    Dernière modification par MikeRowSoft ; 25/02/2017 à 09h40. Motif: (i)

  6. #6
    Membre éclairé Avatar de Beanux
    Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    octobre 2009
    Messages
    249
    Détails du profil
    Informations personnelles :
    Âge : 31
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : octobre 2009
    Messages : 249
    Points : 736
    Points
    736
    Par défaut
    Citation Envoyé par Stéphane le calme Voir le message
    L’une des propriétés des fonctions cryptographiques est le fait qu’elles sont unidirectionnelles ; en clair, il n’est pas possible de retrouver la chaîne originelle à partir du hash. Une seconde est que, théoriquement, deux chaînes de caractères différentes donneront systématiquement deux hash différents. C’est cette théorie que les chercheurs sont parvenus à démentir.
    Je partage l'avis de BlueScreenJunky, avec une fonction de hachage, il est impossible de ne pas avoir de collision.
    Quelque soit la fonction de hachage, si la taille du hash est plus petit que ce que tu cherches à hacher, il y a obligatoirement un risque de collision.
    Pour causer plus math, l'ensemble des résultats de la fonction de hachage (qui est un ensemble fini, vu qu'il a une taille fixe) est un sous ensemble des choses que tu peux hacher (et cet ensemble est infini) parce que tu peux hacher les résultats de ta fonction de hachage. mal dit et un dessin serait plus parlant

    Après, comme il (BlueScreenJunky) le dit, c'est trouver la collision qui elle est plus dur. Mais c'est ça qu'ils ont réussi à améliorer.

    Citation Envoyé par dourouc05 Voir le message
    par défaut, tout le monde devrait les utiliser… En tout cas pour des applications cryptographiques.
    Après le coût de calcul intervient. Selon les support (par exemple les cartes à puces), ce n'est pas forcément possible.
    Après dans ce genre de cas (puces crypto etc), c'est surtout un challenge qui est a relever pour permettre l'authentification, et on peut se contenter d'une fonction crypto "moins sur" mais qu'on sait incassable en un temps donné.

  7. #7
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    4 837
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 4 837
    Points : 125 602
    Points
    125 602
    Par défaut Un développeur teste dans Webkit les deux fichiers PDF servant de PoC pour la collision de hash sur SHA-1
    Un développeur teste dans Webkit les deux fichiers PDF servant de PoC pour la collision de hash sur SHA-1,
    et provoque malencontreusement une panne

    Jeudi dernier, une équipe composée de chercheurs issus du Centrum Wiskunde et Informatica (CWI, Pays-Bas) et de Google a annoncé avoir mis au point une méthode pour briser l'algorithme SHA-1 qui a longtemps été utilisé pour vérifier l'authenticité des documents numériques. Dans le cadre de la rédaction détaillée de leur réalisation, les chercheurs ont également publié deux fichiers PDF comme preuve de la collision réalisée, les deux fichiers ayant des hachages SHA-1 identiques, mais affichant des contenus différents.

    Mais le PoC a provoqué involontairement sa première victime : le système de contrôle de versions utilisé par le moteur de navigateur Webkit a été corrompu après qu’un individu a téléchargé les deux fichiers PDF, qui ont été utilisés comme PoC, sur le référentiel Webkit. Le bogue réside dans Apache Subversion (souvent abrégé SVN, d’après le nom de sa commande svn), un système de contrôle de versions open source que WebKit et d'autres grandes organisations de développement de logiciels utilisent pour garder une trace du code soumis par les membres individuels.

    SVN utilise SHA-1 pour trouver et fusionner des fichiers en double. Cependant, lorsque le système a rencontré les deux fichiers PDF qui ont servi à créer la collision SHA-1, SVN a fait l’expérience d’un bogue qui a engendré des erreurs.

    Selon le rapport de bogue, le dépôt WebKit a été corrompu jeudi lorsque quelqu’un a voulu tester comment le système aurait géré les PDF. Presque immédiatement, le système a connu des échecs. Les erreurs se sont poursuivies jusqu'à vendredi et ont finalement poussé un utilisateur à demander : « est-ce qu’il est possible de résoudre ce problème ? Est-ce que nous allons devoir supprimer tout l’historique SVN depuis ce commit du serveur afin d'éviter la collision hash ? ». Les réponses indiquent que le dépôt est resté au moins partiellement endommagé même après la suppression des fichiers PDF. D’ailleurs, un message sur une liste de diffusion de WebKit a indiqué que les systèmes de mise en miroir ont été dans l’incapacité d'être mis à jour.

    Sur le site dédié à l’évènement autour de la collision de hash (partage des fichiers ayant servis au PoC, séance de Q&R sur ce qui est impliqué et différentes informations relatives à SHA-1) qui a été mis à jour, les chercheurs ont précisé que SVN est affecté : « s'il vous plaît, faites attention, étant donné que les collisions des fichiers SHA-1 brisent actuellement les dépôts SVN. Les serveurs Subversion utilisent SHA-1 pour la déduplication et les référentiels sont corrompus lorsque deux fichiers collisionnels sont affectés au référentiel. Cela a été découvert dans le référentiel Subversion de WebKit et confirmé de manière indépendante par nous. Nous avons remarqué que dans certains cas, en raison de la corruption, d'autres commits sont bloqués ».

    Mais SVN n’est pas le seul affecté étant donné que GIT n’est pas épargné. « GIT s'appuie fortement sur SHA-1 pour l'identification et la vérification de l'intégrité de tous les objets de fichier et commits. Il est essentiellement possible de créer deux référentiels GIT avec le même hachage commit de tête et différents contenus, par exemple un code source bénin et un disposant d’une porte dérobée. Un attaquant pourrait potentiellement servir sélectivement l’un ou l’autre des dépôts aux utilisateurs ciblés. Cela exigera des attaquants de calculer leur propre collision », ont noté les chercheurs.

    Si Firefox avait l’intention de considérer SHA-1 comme étant insécurisé au début de cette année, cette expérience a précipité son action : depuis le 24 février 2017, SHA-1 est désormais déprécié.

    Source : SHAttered, liste de diffusion Webkit, Webkit BugZilla
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  8. #8
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    août 2008
    Messages
    24 980
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 24 980
    Points : 176 288
    Points
    176 288
    Par défaut
    Citation Envoyé par Beanux Voir le message
    Après le coût de calcul intervient. Selon les support (par exemple les cartes à puces), ce n'est pas forcément possible.
    Après dans ce genre de cas (puces crypto etc), c'est surtout un challenge qui est a relever pour permettre l'authentification, et on peut se contenter d'une fonction crypto "moins sur" mais qu'on sait incassable en un temps donné.
    BLAKE2 est un finaliste pour SHA-3 : sa sécurité est très proche de Keccak (qui a été choisi comme SHA-3 au terme de la compétition), mais il est plus rapide à calculer que MD5 (https://leastauthority.com/blog/BLAK...-than-MD5.html). Quelle raison reste-t-il d'utiliser MD5, SHA-1 ?
    Vous souhaitez participer aux rubriques Qt ou PyQt (tutoriels, FAQ, traductions), HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  9. #9
    Expert éminent Avatar de disedorgue
    Homme Profil pro
    Ingénieur intégration
    Inscrit en
    décembre 2012
    Messages
    3 292
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur intégration
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : décembre 2012
    Messages : 3 292
    Points : 9 464
    Points
    9 464
    Par défaut
    Citation Envoyé par Beanux Voir le message
    Je partage l'avis de BlueScreenJunky, avec une fonction de hachage, il est impossible de ne pas avoir de collision.
    Quelque soit la fonction de hachage, si la taille du hash est plus petit que ce que tu cherches à hacher, il y a obligatoirement un risque de collision.
    Pour causer plus math, l'ensemble des résultats de la fonction de hachage (qui est un ensemble fini, vu qu'il a une taille fixe) est un sous ensemble des choses que tu peux hacher (et cet ensemble est infini) parce que tu peux hacher les résultats de ta fonction de hachage. mal dit et un dessin serait plus parlant
    Malheureusement, c'est pas toujours vrai dans la vraie vie: même si le hash est plus petit que que le message que l'on hash...
    Un exemple flagrant, c'est les mots de passe: on peut avoir un mot de passe qui dépasse la taille de son propre hash mais comme on nous restreint souvent d'avoir un mot de passe de taille min et max et de plus sur jeu d'alphabet réduit, la collision peut ne pas se produire puisque l'ensemble des mot de passe est aussi fini.
    Cordialement.

  10. #10
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    février 2011
    Messages
    4 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 79
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : février 2011
    Messages : 4 161
    Points : 12 371
    Points
    12 371
    Par défaut
    Salut à tous.

    Citation Envoyé par Stéphane Le Calme
    Une seconde est que, théoriquement, deux chaînes de caractères différentes donneront systématiquement deux hash différents.
    Désolé pour mon ignorance, mais pourriez vous traduire vos propos au sujet du Hashage.
    Dois-je comprendre que le hashage, c'est comme la fonction modulo. On finit tôt ou tard par retrouver le même cycle.

    Et en quoi la collision a provoqué un gros bug. Je n'ai rien compris de ce problème.

    Merci.
    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  11. #11
    MikeRowSoft
    Invité(e)
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Et en quoi la collision a provoqué un gros bug. Je n'ai rien compris de ce problème.
    Surement pour les droits d'auteurs et autres copyright.
    Numériser la joconde n'est pas pareil que la reproduite. Sa a aussi un taux de correspondance ou similitude.

  12. #12
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    août 2008
    Messages
    24 980
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 24 980
    Points : 176 288
    Points
    176 288
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Désolé pour mon ignorance, mais pourriez vous traduire vos propos au sujet du Hashage.
    Dois-je comprendre que le hashage, c'est comme la fonction modulo. On finit tôt ou tard par retrouver le même cycle.
    Le principe de ces fonctions de hachage, c'est que deux entrées différentes, même légèrement, donneront deux sorties (empreintes) différentes (voire franchement différentes). Il n'y pas vraiment de notion de cycle. Les chercheurs ont trouvé un moyen de produire une collision, c'est-à-dire trouver deux fichiers qui ont la même empreinte par SHA-1.

    Le problème, ici, c'est que SVN détermine si deux fichiers sont différents par un test sur le résultat d'une fonction de hachage : dans l'immensément grande majorité des cas, c'est suffisant ; grâce à cette collision, cette technique a été mise à mal, d'où le problème.
    Vous souhaitez participer aux rubriques Qt ou PyQt (tutoriels, FAQ, traductions), HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  13. #13
    Expert confirmé
    Homme Profil pro
    Étudiant
    Inscrit en
    juin 2012
    Messages
    1 706
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2012
    Messages : 1 706
    Points : 4 378
    Points
    4 378
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Dois-je comprendre que le hashage, c'est comme la fonction modulo. On finit tôt ou tard par retrouver le même cycle.
    Cycle je sais pas (j'imagine qu'ils essaient d'éviter); mais plusieurs fichiers peuvent avoir le même hash, oui.

    Citation Envoyé par Artemus24 Voir le message
    Et en quoi la collision a provoqué un gros bug. Je n'ai rien compris de ce problème.
    Un fichier est un grand nombre (exemple, un fichier d'1Mo => 2^8096 => ~10^2730); un hash est un "petit" nombre (160 bits pour SHA-1 => ~10^53).

    Il n'y a "que" 10^53 hashs différents, et une infinité de fichiers possible en entrée => plusieurs (une infinité) fichiers auront le même hash.
    Quand 2 fichiers différents ont le même hash, c'est une collision. Les fonctions de hashages sont faites pour que les collisions soient rares et non prévisibles (preuve de la rareté, le bug de SVN vient seulement d'être trouvé).

    Le hashage est utilisé pour vérifier qu'un fichier (ou n'importe quel autre contenu) n'ai pas été altéré (sinon son hash change); si on est capable de créer des collisions, le hashage ne sert plus à rien puisqu'on peut altérer un fichier sans modifier son hash.

  14. #14
    Membre éclairé Avatar de Beanux
    Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    octobre 2009
    Messages
    249
    Détails du profil
    Informations personnelles :
    Âge : 31
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : octobre 2009
    Messages : 249
    Points : 736
    Points
    736
    Par défaut
    Je pense qu'a la base on est partie sur les hash de fichiers, alors que de toute façon, pour les fichiers la collision existe obligatoirement.

    @Artemus24, voit la fonction de hashage comme un moyen d'identification de quelque chose, mot de passe fichier ou autre. Là, des chercheurs ont montré qu'on peut trouver un autre fichier/mot de passe qui aurait le même hash/"identifiant".

    Pour expliquer plus dans le détail, par exemple, les sites web stockent les mot de passe sous forme de hash (pour simplifier). Si on arrive à récupérer la base de données, tu récupères les hash, et donc tu peux construire un autre mot de passe basé la dessus.
    Il y a le même principe avec les torrent. les fichiers sont identifié avec un hash.
    Quand tu télécharges un fichier par ce biais, ton client compare le hash et indique si c’est bien le bon fichier. Le fait que deux fichier puissent avoir le même hash, signifie que tu pourrait envoyer un fichier malicieux en lui ayant donné le même hash, via des torrent qui sont sains (exemple, les distributions linux entre autre).

    @dourouc05 a priori aucune raison. Même dans le cas de vérifier les téléchargement de fichiers. Mais les habitudes ont la vie dure.

  15. #15
    MikeRowSoft
    Invité(e)
    Par défaut
    Citation Envoyé par dourouc05 Voir le message
    Le principe de ces fonctions de hachage, c'est que deux entrées différentes, même légèrement, donneront deux sorties (empreintes) différentes (voire franchement différentes)
    Dans se cas le passe de l'hexa au octect pour la représentation du codage montre elle une différence ? (chose qui n'est plus du tous la fonction de hashage.)

    Je serais très intéréssé de connaitre les caractéristiques des mots de passe qui seraient concernés. nombre de caractères et ansi table, ascii table, arbre, intelligence artificielle ?
    Dernière modification par MikeRowSoft ; 26/02/2017 à 09h20.

  16. #16
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    février 2011
    Messages
    4 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 79
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : février 2011
    Messages : 4 161
    Points : 12 371
    Points
    12 371
    Par défaut
    Salut à tous.

    Citation Envoyé par dourouc05
    Il n'y pas vraiment de notion de cycle.
    Je parlais du modulo, en tant que comparaison vis-à-vis du hashage, afin d'illustrer le comportement tel que je le comprends.
    Prenons par exemple le modulo 97. Si je prends comme valeur 1.000.000 et 803.
    Ils sont bien différents et pourtant produisent le même reste de la division par 97.
    --> 1.000.000 modulo 97 donne 27.
    --> 803 modulo 97 donne 27.

    J'espère que mon exemple est un peu plus parlant !

    Citation Envoyé par dourouc05
    Les chercheurs ont trouvé un moyen de produire une collision, c'est-à-dire trouver deux fichiers qui ont la même empreinte par SHA-1.
    En quoi deux fichiers différents produisant la même empreinte, peuvent créer un bug ???

    Citation Envoyé par dourouc05
    Le problème, ici, c'est que SVN détermine si deux fichiers sont différents par un test sur le résultat d'une fonction de hachage : dans l'immensément grande majorité des cas, c'est suffisant
    Je croyais que le hashage avait pour but de chiffrer un fichier, et c'est tout. Et que vient faire la comparaison entre ces deux fichiers ???
    Quel est le but justement de cette comparaison et pourquoi le fait qu'ils produisent la même emprunte provoque un bug ?

    Citation Envoyé par dourouc05
    grâce à cette collision, cette technique a été mise à mal, d'où le problème.
    Il faudrait encore comprendre cette technique, qui dans la finalité, en cas de collision, va provoquer un bug.

    Citation Envoyé par Iradrille
    Cycle je sais pas (j'imagine qu'ils essaient d'éviter);
    Je crois que je ne me suis pas bien fait comprendre en ce qui concerne le terme inapproprié de cycle.

    Disons que vous avez une infinité de fichiers, à l'identique des nombres naturels (1, 2, 3, 4, ..., N).
    Quand je calcule le modulo 97 de deux nombres, il est possible d'avoir deux nombres différents, qui produises le même reste.
    C'est de cela dont je voulais parler.

    Citation Envoyé par Iradrille
    mais plusieurs fichiers peuvent avoir le même hash, oui.
    Donc mon exemple est identique à ce qui se passe pour le hashage. Enfin je crois.

    Citation Envoyé par Iradrille
    Quand 2 fichiers différents ont le même hash, c'est une collision.
    L'exemple du modulo est en complète conformité de votre exemple.
    Pour deux nombres différents produisant le même modulo est considéré comme une collision.
    Admettons que cela soit juste une terminologie qui a un sens ici, et que je ne comprends pas très bien vis-à-vis du bug qu'il provoque.

    Citation Envoyé par Iradrille
    Les fonctions de hashages sont faites pour que les collisions soient rares et non prévisibles (preuve de la rareté, le bug de SVN vient seulement d'être trouvé).
    C'est ce que représente la collision que je ne comprends pas bien.
    En quoi deux fichiers différents, produisant la même emprunte est source de problème ?

    Citation Envoyé par Iradrille
    si on est capable de créer des collisions, le hashage ne sert plus à rien puisqu'on peut altérer un fichier sans modifier son hash.
    Maintenant, je comprends mieux. L'emprunte est une garantie de la non altérabilité d'un fichier.
    Même si le cas qui est ici décrit est fort rare, vis-à-vis de ceci : (160 bits pour SHA-1 => ~10^53), et même en augmentant à 2048 bits, le problème continuera d'exister.
    Oui, je sais, le cas avec 2048 bits sera encore plus rare que celui à 160 bits.
    Mais ne croyez-vous pas que le principe du hashage, soit complètement utopique ?

    Citation Envoyé par Beanux
    Si on arrive à récupérer la base de données, tu récupères les hash, et donc tu peux construire un autre mot de passe basé la dessus.
    Je ne voie pas trop l'intérêt de ce que vous avancez car l'algorithme de chiffrement est connu de tout le monde.
    Je parle bien sûr du chiffrement qui va de la phrase en clair ==> la phrase chiffrée.
    Dans votre base de données, vous connaissez que la phrase chiffrée.
    L'opération inverse est impossible car la réversibilité du chiffrement n'est pas possible.
    Le seul moyen de contourner le problème, si j'ai bien compris vos explications à tous, c'est de trouver une autre phrase en clair, qui par le chiffrement, donnera la même phrase chiffrée ci-avant.

    Oui, mais un cas particulier ne peut pas remettre en cause le fonctionnement de ce sha-1.
    Aujourd'hui, nous avons des milliers de morts sur la route, ce n'est pas pour autant que l'on a interdit les voitures d'y circuler.

    Citation Envoyé par Stéphane le calme
    « s'il vous plaît, faites attention, étant donné que les collisions des fichiers SHA-1 brisent actuellement les dépôts SVN. Les serveurs Subversion utilisent SHA-1 pour la déduplication et les référentiels sont corrompus lorsque deux fichiers collisionnels sont affectés au référentiel. Cela a été découvert dans le référentiel Subversion de WebKit et confirmé de manière indépendante par nous. Nous avons remarqué que dans certains cas, en raison de la corruption, d'autres commits sont bloqués ».
    C'est ce que disent les chercheurs que je ne comprends pas. Et pourquoi cela provoque un bug en cascade si j'ai bien compris !

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  17. #17
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    août 2008
    Messages
    24 980
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 24 980
    Points : 176 288
    Points
    176 288
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Je croyais que le hashage avait pour but de chiffrer un fichier, et c'est tout. Et que vient faire la comparaison entre ces deux fichiers ???
    Quel est le but justement de cette comparaison et pourquoi le fait qu'ils produisent la même emprunte provoque un bug ?
    Pour reprendre ton parallélisme avec les fonctions modulo : le hachage n'a pas l'objectif de chiffrer quoi que ce soit, juste de donner une empreinte de taille réduite. Un SHA-1 te donne une empreinte de 20 octets : impossible de retrouver le fichier d'origine de façon unique avec seulement ces 20 octets — tout comme il est impossible d'inverser ta fonction modulo pour retrouver 1 000 000 ou 803 depuis 27.

    Citation Envoyé par Artemus24 Voir le message
    Oui, mais un cas particulier ne peut pas remettre en cause le fonctionnement de ce sha-1.
    Justement, ce n'est pas qu'un cas particulier : on a maintenant une technique qui permet de créer des collisions comme et quand on veut, avec des moyens "limités" (en tout cas, rien qui soit hors de portée d'une agence gouvernementale).

    Citation Envoyé par Artemus24 Voir le message
    Mais ne croyez-vous pas que le principe du hashage, soit complètement utopique ?
    On cherche surtout à ce que créer une collision soit extrêmement difficile pour un attaquant. On peut survivre sans une fonction parfaite en sécurité.
    Vous souhaitez participer aux rubriques Qt ou PyQt (tutoriels, FAQ, traductions), HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  18. #18
    Membre éclairé Avatar de Beanux
    Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    octobre 2009
    Messages
    249
    Détails du profil
    Informations personnelles :
    Âge : 31
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : octobre 2009
    Messages : 249
    Points : 736
    Points
    736
    Par défaut
    @Artemus24

    Donc pour reprendre, le hashage, c’est une fonction. Pas un programme informatique ou autre. Comme la fonction addition (7+8) qui fait qu' l'on prend le premier nombre que l'on ajoute au deuxième, ce qui nous donne 15, ce sont des mathématiques. Il n'y a aucun bug. C'est très important de comprendre cela.
    Il peut y avoir des bugs quand on traduit la fonction en un programme. Mais avant ça la fonction de hashage, elle existe en dehors de toute conception informatique, seulement mathématique.

    Autre chose juste pour éviter des confusions, si l'on parle de fonction de hachage, il vaut mieux parler de d'encrypter, ou d'utiliser la racine crypter, plutôt que chiffrer. Parce que dans sa définition le chiffrement est réversible, celui du d’encrypter ne l'est pas.

    Citation Envoyé par Artemus24 Voir le message
    Disons que vous avez une infinité de fichiers, à l'identique des nombres naturels (1, 2, 3, 4, ..., N).
    Quand je calcule le modulo 97 de deux nombres, il est possible d'avoir deux nombres différents, qui produises le même reste.
    C'est de cela dont je voulais parler.
    Pour la comparaison avec le modulo, elle est peu approprié. Parce qu'il n'y a pas de relation d'ordre avec les fonction de hachage.
    Cette notion de cycle c'est ce qui est appelé collision, c’est à dire que pour 2 hash donnés, il y a un même résultat.
    Oui cela existe, oui toutes les fonctions de hachage ont des collisions (ce que vous avez nommé "cycles"), mais ce qui est important c'est de ne pas arriver à partir du hash à trouver un résultat potentiel qui a mené à ce hash.

    Citation Envoyé par Artemus24 Voir le message
    Le seul moyen de contourner le problème, si j'ai bien compris vos explications à tous, c'est de trouver une autre phrase en clair, qui par le chiffrement, donnera la même phrase chiffrée ci-avant.
    Exemple, si je donne le hash "abec64d508a87095ac33f69e1fa40f591b5c5c14", il est a peu près impossible de trouver que "ceci est un hash" a été sa source. Et il est a peu près impossible de trouver un quelconque texte/fichier qui pourrait générer ce hash. Enfin a peu près sauf depuis la publication qui est à l'origine de cet article.
    Ici, le modulo est un bon exemple, si on me donne x mod 97 = 3, trouver un x est simple, mais trouver le x que moi j'ai utilisé pour générer ce 3, n'est pas possible. J'ai utilisé 488, mais cela aurait pu être 353374, ou tout aussi bien 3. Sauf que le modulo génère des collision bien trop élevées.

    Citation Envoyé par Artemus24 Voir le message
    Maintenant, je comprends mieux. L'emprunte est une garantie de la non altérabilité d'un fichier.
    Même si le cas qui est ici décrit est fort rare, vis-à-vis de ceci : (160 bits pour SHA-1 => ~10^53), et même en augmentant à 2048 bits, le problème continuera d'exister.
    Oui, je sais, le cas avec 2048 bits sera encore plus rare que celui à 160 bits.
    Mais ne croyez-vous pas que le principe du hashage, soit complètement utopique ?
    L'important n'est pas la probabilité de collision. Qui elle est complétement utopique. Elle est et sera toujours présente. on prend un entrée un nombre infini de possibilité pour le réduire à un nombre fini; Il y aura toujours de collisions, c'est inévitable.
    Et ce n’est pas l’important, l'important est qu'il soit impossible ou extrêmement difficile a partir du hash de retrouver sa source (cf exemple au dessus dans mon message), et que les probabilité de collision soit tout de même assez basses pour permettre une sécurité suffisante.


    Citation Envoyé par Artemus24 Voir le message
    Je ne voie pas trop l'intérêt de ce que vous avancez car l'algorithme de chiffrement est connu de tout le monde.
    Je parle bien sûr du chiffrement qui va de la phrase en clair ==> la phrase chiffrée.
    Dans votre base de données, vous connaissez que la phrase chiffrée.
    L'opération inverse est impossible car la réversibilité du chiffrement n'est pas possible.
    Le seul moyen de contourner le problème, si j'ai bien compris vos explications à tous, c'est de trouver une autre phrase en clair, qui par le chiffrement, donnera la même phrase chiffrée ci-avant.

    Oui, mais un cas particulier ne peut pas remettre en cause le fonctionnement de ce sha-1.
    Justement le papier des chercheur dit qu'a partir du hash, il est possible trouver une phrase en claire qui fournira ce hash. Peut importe si cette phrase en clair a réellement été celle qui a servit à générer le hash. Le problème et qu'a partir du hash, il soit possible de trouver quelque chose qui puisse générer ce hash.

    En pratique ça veux dire que si j'ai le hash de votre mot de passe de developpez.net (si ils utilisent ce système, et si ils n'ont pas ajouté d'autres systèmes de sécurité), je peux avoir accès a votre compte sans connaitre votre mot de passe.
    Et ça c’est un problème. la possibilité de faire passer pour autre chose quelque chose qui ne l'est pas, en ayant que le hash à sa disposition.

  19. #19
    Expert confirmé
    Avatar de TiranusKBX
    Homme Profil pro
    Développeur C, C++, C#, Python, PHP, HTML, JS
    Inscrit en
    avril 2013
    Messages
    1 476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur C, C++, C#, Python, PHP, HTML, JS
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2013
    Messages : 1 476
    Points : 4 852
    Points
    4 852
    Billets dans le blog
    6
    Par défaut
    Ha! ça me fait marrer
    Depuis le temps tous le monde devrait savoir que pour éviter ce problème il faut utiliser à minima 2 algorithmes de Hash et utiliser leur 2 ou plus références, mais non on préfère accorder toute nôtre confiance à une seule serrure sur la porte
    merci de me mettre des quand mes messages sont pertinent, et pour les pas contents voici mon service client pour eux

    [Projet en cours] Strategy(nom provisoire) - Advance wars like
    cordova-plugin-file-hash Plugin cordova servant à obtenir le hash d'un fichier

  20. #20
    MikeRowSoft
    Invité(e)
    Par défaut
    Citation Envoyé par dourouc05 Voir le message
    Un SHA-1 te donne une empreinte de 20 octets : impossible de retrouver le fichier d'origine de façon unique avec seulement ces 20 octets — tout comme il est impossible d'inverser ta fonction modulo pour retrouver 1 000 000 ou 803 depuis 27.
    Si le calcule est comme une suite mathématique (parcours séquentiel du fichier ou des fichiers) qui à un instant peu avoir deux valeurs différente comme résultat et simultanément tous en ayant aucun caractère aléatoire, le problème viens donc de l'algorithme de base lui même.

    Maintenant, j'ai compris, c'est un algorithme et donc pas forcément mathématique.

    Pas de code auto correcteur inclus (j'ai encore mieux compris ?).

Discussions similaires

  1. Des chercheurs utilisent nos tweets pour mesurer notre santé mentale
    Par Amine Horseman dans le forum Actualités
    Réponses: 6
    Dernier message: 02/01/2015, 14h48
  2. Des chercheurs du MIT créent KLOS, un algorithme puissant de parcours de graphe non orienté
    Par Cedric Chevalier dans le forum Algorithmes et structures de données
    Réponses: 11
    Dernier message: 21/01/2014, 23h46
  3. Réponses: 1
    Dernier message: 01/11/2013, 17h50
  4. Des chercheurs utilisent NAO pour communiquer avec des autistes
    Par Stéphane le calme dans le forum Actualités
    Réponses: 3
    Dernier message: 22/03/2013, 16h45
  5. Des chercheurs utilisent des bactéries pour stocker des données
    Par Katleen Erna dans le forum Actualités
    Réponses: 45
    Dernier message: 19/01/2011, 04h37

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo