Je prends des cours sur la Blockchain en anglais et c'est pas souvent aisé de comprendre certains concepts. Vous n'y avez aidé magistralement!!! Votre vocabulaire est simple, des exemples épurés et bien illustrés Merci !!!
Les fonctions de hashage ont beaucoup d'applications, il y a effectivement des applications dans la cybersécurité et on les utilisent beaucoup pour ça de nos jours. Mais c'est quand même très important de savoir que beaucoup d'autre applications existent. Par exemple pour les communications on utilise des sommes de contrôle, des CRC, ou même des fois tout simplement un bit de parité. Mais on les utilisent aussi dans les mémoires RAM des ordinateurs, on appel ça un ECC pour détecter les modifications de bit dans la mémoire causé par des rayons cosmiques ou d'autre sorte d'erreur (c'est des erreurs très rare, mais il faut pouvoir les détecter). On peut aussi les utiliser comme dans les cryptomonnaies comme preuve de travail bien-sur. On les retrouves aussi dans les systèmes d'adressage multi-banqué des mémoires caches des ordinateurs, comme avec le Complex Addressing du LLC (Last Level Cache) sur les processeurs Intel. Et encore un tas d'autre application (les tables de hash, comparaison de fichier, ...). Et justement le choix de la fonction de hashage et de ses dépendant est TRÈS dépendant de l'application :) !
Un hash est donc un checksum? Merci Lê pour cette super série de vidéo, qui est un outils pédagogique génial! Je suis ta chaîne Science4all depuis quelques années et j’adore et admire ton travail, particulièrement ton travail actuel sur les IA!
Hi :) merci pour le partage! Meme si tout n est pas expliqué , les grandes lignes sont là :) et vive le bitcoin par l occasion, j ai encore du mal à comprendre pourquoi tant de gens n en ont pas alors que c est juste l avenir ...
Très bonne vidéo, comme d'habitude ^^ J'aimerais quand même ajouter quelque détails : il y a régulièrement de nouvelle fonction de hachage inventer (pas tous les jours non plus, parce que ça reste un problème complexe à résoudre). Et les anciennes fonctions sont dépréciés quand on trouve qu'une des propriétés n'est pas respecter. Par exemple SHA (ou SHA1, vu qu'il y en a plusieurs maintenant), fut pendant très longetmps considéré comme sur, a tel point qu'on l'utilise dans des outils comme Git. D'ailleurs aujourd'hui on a des bon candidat comme BLAKE2 (qui sera SHA3) et utilise un algo un peu différent des précédents SHA. Tous ça pour dire que l'argument à la fin de dire qu'on a vraiment confiance en SHA-256 car il est utilisé par la Blockchain est pour moi, pas à 100% juste.
Petite correction Git utilise un SHA-2 (256b) en interne mais présente dans sa version courte des SHA-1 plus facile à lire. Le hashage complet reste disponible. Autre point, l'élection d'un standard comme SHA-3 se fait via un concours organisé par le NIST (National Institute of Standards and Technology). Lors du dernier concours BLAKE a été recalé au profit de Keccak et Blake2 est arrivé après le concours. Le standard SHA-3 est pour le moment Keccak. Il le restera jusqu'au prochain concours (csrc.nist.gov/projects/hash-functions/sha-3-project). Ceci étant je reste d'accord avec l'idée que l'usage d'un algorithme ne le rend pas plus ou moins sûr...
Bonjour ! . Après avoir envoyé des cryptomonnaies à un individu , est-il dangereux de lui envoyer l'adresse du hash pour une vérification éventuelle ? .
Sympa de prendre ça comme sujet J'ajoute que plus que le bitcoin c'est surtout utilisé pour les mots de passe et la signatures de logiciels type OS et dans une autre dimension le protocole https.
La prédictibilité ! Pour qu'un hashage soit considéré comme acceptable (attention on ne dit jamais parfait !), il faut qu'aucune règle mathématique puisse permettre de converger vers une prédiction quasi-similaire à celle de l'algorithme en charge du hashage. Ainsi éviter des nœuds mathématiques qui pourrait arriver quand on décide de calculer un très grand nombre d'opérations mathématiques. Par exemple, si on prend le nombre 3 et que l'on ajoute 8 plusieurs fois, on obtient une suite qui se finit toujours par : 3 1 9 7 5 - c'est très facile dans deviner la suite pour n éléments ; cracker un hash c'est plus compliqué même si ça se base sur un tel cas d'école. Le dernier élément à tester, évoqué par Lê dans sa vidéo, c'est l'estimation du risque de collision : quand deux valeurs proches peuvent produire le même hash. La plus petite collision correspond à la qualité d'un hash. Ainsi on peut facilement le comparer avec d'autres pour savoir lequel on préféra utiliser pour la sécurité des systèmes d'informations (systèmes bancaires notamment). C'est pourquoi les méthodes de hash évoluent, aucune n'est parfaite malheureusement, le sha1 et le md5 c'est de l'histoire ancienne et aujourd'hui c'est la méthode Keccak (dont SHA-256 en fait partie). edit: comme le dit Nicolas JUHEL dans les commentaires, le choix du standard est très lié à un concours organisé par le NIST (National Institute of Standards and Technology) mais bien sûr ça ne suffit pas !
@@doryanngartner2660 pour vérifier l'intégrité des fichiers oui, pour générer des nombres aléatoires oui aussi, pour générer des tokens oui oui oui. Mais si tu cherches à sécuriser des mots de passes dans une BDD, faut absolument éviter. Je te renvois aux références de l'article Wikipédia : fr.wikipedia.org/wiki/MD5#Cryptanalyse . "En tout cas la dernière fois que j'en ai bidouillé, ça n'a mené à rien" libre à toi d'essayer les solutions de cryptanalyse et pas de te contenter de ton "expérience".
@@Yarflam Eh bien merci, cependant, mon "expérience" remonte à loin et je suis loin d'être expert. Je me suis mal formulé, en disant cela. Mais je ne savais pas tout cela, donc merci beaucoup. Bonne journée.
Non du tout, une somme de contrôle a un effet sur des petites quantités de données. On se restreint par exemple à enregistrer 7 bits sur un octet et prendre le dernier pour savoir si le nombre de bit à 1 dans l'octet est paire (1) ou impaire (0), si au moment de vérifier, le résultat est différent, il est facile de dire qu'une partie des données a été mal transmise. Des méthodes plus avancés (notamment en utilisant des redondances comme dans les QrCodes) permettent d'effectuer des corrections automatiques (ça fait appel aux notions de Shannon sur les échanges de données sur un flux sensible aux bruits / à l'altération, par exemple dans l'environnement du spatiale entre un rover Martien et un centre de recherche Terrestre - ce serait terrible de ne pas recevoir la photo ou à moitié altéré ! Pire si ce sont des échantillons de sols). La méthode de hashage, elle va concaténer intelligemment un fichier pour ne donner qu'une chaîne plus petite - peut importe la taille, si le contenu est inférieur (à par exemple 256 bits) on complète avec des constantes et on l’agrège de la même manière. Avec il n'est pas possible de corriger les données, ni même d'effectuer la moindre interprétation sur les données d'origines. On peut au mieux stocker en base le lien direct entre X (la donnée brute) et Y (le hashage) pour notamment cracker les mots de passe. On peut également garder une unicité aux données, mettre en place un système en cache ou s'assurer comme le dit Lê qu'un ouvrage est intégralement transmis ou qu'une application n'a pas été piraté au passage (ce qui ne pourrait pas être détecté avec une somme de contrôle car le téléchargement s'est bien déroulé si l'application peut se lancer).
Depuis quand, la somme de contrôle a un effet sur des petites quantités de données ? CRC16, CRC32, SHASUM1, SHASUM256, etc ne changent que par la méthode.
Ouai c'était bancale :p je voulais dire qu'avec les checksum on travaille sur quelques bits / octets puis on répète l'opération, alors que le hash est calculé sur l'ensemble des bits (lui même subdivisé par des petites opérations, par exemple des XOR).
Je prends des cours sur la Blockchain en anglais et c'est pas souvent aisé de comprendre certains concepts. Vous n'y avez aidé magistralement!!! Votre vocabulaire est simple, des exemples épurés et bien illustrés Merci !!!
Les fonctions de hashage ont beaucoup d'applications, il y a effectivement des applications dans la cybersécurité et on les utilisent beaucoup pour ça de nos jours.
Mais c'est quand même très important de savoir que beaucoup d'autre applications existent.
Par exemple pour les communications on utilise des sommes de contrôle, des CRC, ou même des fois tout simplement un bit de parité.
Mais on les utilisent aussi dans les mémoires RAM des ordinateurs, on appel ça un ECC pour détecter les modifications de bit dans la mémoire causé par des rayons cosmiques ou d'autre sorte d'erreur (c'est des erreurs très rare, mais il faut pouvoir les détecter).
On peut aussi les utiliser comme dans les cryptomonnaies comme preuve de travail bien-sur.
On les retrouves aussi dans les systèmes d'adressage multi-banqué des mémoires caches des ordinateurs, comme avec le Complex Addressing du LLC (Last Level Cache) sur les processeurs Intel.
Et encore un tas d'autre application (les tables de hash, comparaison de fichier, ...). Et justement le choix de la fonction de hashage et de ses dépendant est TRÈS dépendant de l'application :) !
Ce qu'il y a de bien avec String Theory, c'est que je comprends tout dans une vidéo présentée par Lê :)
Bravo pour la présentation, simple a comprendre...
Un hash est donc un checksum? Merci Lê pour cette super série de vidéo, qui est un outils pédagogique génial! Je suis ta chaîne Science4all depuis quelques années et j’adore et admire ton travail, particulièrement ton travail actuel sur les IA!
Super vidéo résumé !
très bonne vidéo très intéressante 😃
Très bonne vidéo Lê !
Hi :) merci pour le partage! Meme si tout n est pas expliqué , les grandes lignes sont là :) et vive le bitcoin par l occasion, j ai encore du mal à comprendre pourquoi tant de gens n en ont pas alors que c est juste l avenir ...
Très bonne vidéo, comme d'habitude ^^ J'aimerais quand même ajouter quelque détails : il y a régulièrement de nouvelle fonction de hachage inventer (pas tous les jours non plus, parce que ça reste un problème complexe à résoudre). Et les anciennes fonctions sont dépréciés quand on trouve qu'une des propriétés n'est pas respecter. Par exemple SHA (ou SHA1, vu qu'il y en a plusieurs maintenant), fut pendant très longetmps considéré comme sur, a tel point qu'on l'utilise dans des outils comme Git. D'ailleurs aujourd'hui on a des bon candidat comme BLAKE2 (qui sera SHA3) et utilise un algo un peu différent des précédents SHA. Tous ça pour dire que l'argument à la fin de dire qu'on a vraiment confiance en SHA-256 car il est utilisé par la Blockchain est pour moi, pas à 100% juste.
Petite correction Git utilise un SHA-2 (256b) en interne mais présente dans sa version courte des SHA-1 plus facile à lire. Le hashage complet reste disponible.
Autre point, l'élection d'un standard comme SHA-3 se fait via un concours organisé par le NIST (National Institute of Standards and Technology). Lors du dernier concours BLAKE a été recalé au profit de Keccak et Blake2 est arrivé après le concours. Le standard SHA-3 est pour le moment Keccak. Il le restera jusqu'au prochain concours (csrc.nist.gov/projects/hash-functions/sha-3-project).
Ceci étant je reste d'accord avec l'idée que l'usage d'un algorithme ne le rend pas plus ou moins sûr...
@@Jakkobar merci pour les corrections et les précisions ^^
J'aime beaucoup ! Je comprends mieux !
EPFL, vous êtes les meilleurs!
Merci pour cette explication!
Très bonnes video ! C'est fait exprès le cadenas sur la table ? 😉
Bah perso, c'est la fourchette qui me perturbe... ^^
+Alexandre Ancel Bah si on hache de la viande, il faut bien la manger
Ah oui, effectivement, j'y avais pas pensé ! x'D
Pourquoi parmi les 5 propriétés celle du calcul rapide n’est pas prouvée vers 4’50 ?
Super intéressant!
le lien vers la chaine de science4all est mauvais, et il est même pas en chaine recommander par string theorie...
Bonjour ! .
Après avoir envoyé des cryptomonnaies à un individu , est-il dangereux de lui envoyer l'adresse du hash pour une vérification éventuelle ? .
Sympa de prendre ça comme sujet
J'ajoute que plus que le bitcoin c'est surtout utilisé pour les mots de passe et la signatures de logiciels type OS et dans une autre dimension le protocole https.
Intéressant!
C quoi la constante de structure fine ?
J'en connais un qui a regardé UFO 😉
J'aime beaucoup la fork(-256) à côté du padlock :)
Les éléments d'Euclide contiendraient la réponse à la grande question sur la vie, l'univers et le reste ?
Quelle est la différence entre un bon hashage et un mauvais hashage ?
La prédictibilité ! Pour qu'un hashage soit considéré comme acceptable (attention on ne dit jamais parfait !), il faut qu'aucune règle mathématique puisse permettre de converger vers une prédiction quasi-similaire à celle de l'algorithme en charge du hashage. Ainsi éviter des nœuds mathématiques qui pourrait arriver quand on décide de calculer un très grand nombre d'opérations mathématiques. Par exemple, si on prend le nombre 3 et que l'on ajoute 8 plusieurs fois, on obtient une suite qui se finit toujours par : 3 1 9 7 5 - c'est très facile dans deviner la suite pour n éléments ; cracker un hash c'est plus compliqué même si ça se base sur un tel cas d'école. Le dernier élément à tester, évoqué par Lê dans sa vidéo, c'est l'estimation du risque de collision : quand deux valeurs proches peuvent produire le même hash. La plus petite collision correspond à la qualité d'un hash. Ainsi on peut facilement le comparer avec d'autres pour savoir lequel on préféra utiliser pour la sécurité des systèmes d'informations (systèmes bancaires notamment). C'est pourquoi les méthodes de hash évoluent, aucune n'est parfaite malheureusement, le sha1 et le md5 c'est de l'histoire ancienne et aujourd'hui c'est la méthode Keccak (dont SHA-256 en fait partie).
edit: comme le dit Nicolas JUHEL dans les commentaires, le choix du standard est très lié à un concours organisé par le NIST (National Institute of Standards and Technology) mais bien sûr ça ne suffit pas !
@@Yarflam le md5 reste encore une excellente sécurité. En tout cas la dernière fois que j'en ai bidouillé, ça n'a mené à rien 😁
@@doryanngartner2660 pour vérifier l'intégrité des fichiers oui, pour générer des nombres aléatoires oui aussi, pour générer des tokens oui oui oui. Mais si tu cherches à sécuriser des mots de passes dans une BDD, faut absolument éviter. Je te renvois aux références de l'article Wikipédia : fr.wikipedia.org/wiki/MD5#Cryptanalyse .
"En tout cas la dernière fois que j'en ai bidouillé, ça n'a mené à rien" libre à toi d'essayer les solutions de cryptanalyse et pas de te contenter de ton "expérience".
@@Yarflam Eh bien merci, cependant, mon "expérience" remonte à loin et je suis loin d'être expert. Je me suis mal formulé, en disant cela.
Mais je ne savais pas tout cela, donc merci beaucoup.
Bonne journée.
42... évidemment !
T'es pas Suisse Lê, ou du moins t'étais à l'EPFL?
Je soupçonne le fond bleu (ou vert...) pour String Theory
@@pierreswing9165 ?
ah... je pensais que le hashage c'était comme tenshirock le hasher
Cette vidéo n'apprend pas grand-chose et on ne dit pas "hashage" mais "somme de contrôle" (checksum en anglais).
Non du tout, une somme de contrôle a un effet sur des petites quantités de données. On se restreint par exemple à enregistrer 7 bits sur un octet et prendre le dernier pour savoir si le nombre de bit à 1 dans l'octet est paire (1) ou impaire (0), si au moment de vérifier, le résultat est différent, il est facile de dire qu'une partie des données a été mal transmise. Des méthodes plus avancés (notamment en utilisant des redondances comme dans les QrCodes) permettent d'effectuer des corrections automatiques (ça fait appel aux notions de Shannon sur les échanges de données sur un flux sensible aux bruits / à l'altération, par exemple dans l'environnement du spatiale entre un rover Martien et un centre de recherche Terrestre - ce serait terrible de ne pas recevoir la photo ou à moitié altéré ! Pire si ce sont des échantillons de sols).
La méthode de hashage, elle va concaténer intelligemment un fichier pour ne donner qu'une chaîne plus petite - peut importe la taille, si le contenu est inférieur (à par exemple 256 bits) on complète avec des constantes et on l’agrège de la même manière. Avec il n'est pas possible de corriger les données, ni même d'effectuer la moindre interprétation sur les données d'origines. On peut au mieux stocker en base le lien direct entre X (la donnée brute) et Y (le hashage) pour notamment cracker les mots de passe. On peut également garder une unicité aux données, mettre en place un système en cache ou s'assurer comme le dit Lê qu'un ouvrage est intégralement transmis ou qu'une application n'a pas été piraté au passage (ce qui ne pourrait pas être détecté avec une somme de contrôle car le téléchargement s'est bien déroulé si l'application peut se lancer).
Depuis quand, la somme de contrôle a un effet sur des petites quantités de données ? CRC16, CRC32, SHASUM1, SHASUM256, etc ne changent que par la méthode.
Ouai c'était bancale :p je voulais dire qu'avec les checksum on travaille sur quelques bits / octets puis on répète l'opération, alors que le hash est calculé sur l'ensemble des bits (lui même subdivisé par des petites opérations, par exemple des XOR).
Tu dois être un sacrément bon hacker. White hat, bien entendu. Moi, je rame un peu avec metasploit, dans mon réseau virtuel, bien entendu.
Je veux pas te vexer loin de la tu fais du super boulot mais c'est pas un peu clichés une personne d'origine asiatiques parle qui sur l'informatique
non