Cryptographie. TD 3 Fonctions de hachage

Cryptographie TD 3 Fonctions de hachage Questions générales : 1) Comment un message est-il modifié par une fonction de hachage? Une fonction de hachage prend en entrée un message de taille arbitraire, et produit une empreinte de taille réduite. L'objectif est qu'une modification même infime du message modifie grandement l'empreinte obtenue. 2) Quels sont les propriétés principales des fonctions de hachage? - Fonction à sens unique : impossible (très difficile) de partir d'une empreinte et d'obtenir un message correspondant - Résistance faible aux collisions : à partir d'un message donné, impossible de trouver un autre message ayant la même empreinte. - Résistance forte aux collisions : impossible de trouver deux messages arbitraires ayant la même empreinte. - De plus : grande propagation de toute modification sur l'entrée. 3) Citer quelques algorithmes. Lesquels sont encore considéré comme surs? Qui choisit les algorithmes à utiliser? - MD2,4,5,6. RIPEMD. SHA-0, SHA-1, SHA-2 - Bientôt, SHA-3. Candidats : BLAKE, Grostl, JH, Keccak, Skein - Concours du NIST - SHA-1 encore sur, SHA-2 pareil. Choix d'un successeur par mesure de sécurité. 4) Y a-t-il une limite à l'entrée d'une fonction de hachage? Si oui, laquelle? En théorie, aucune limite. En pratique, certains algorithmes peuvent exhiber des comportements particuliers quand on dépasse une certaine longueure, en particulier quand cette longueur est utilisée dans le calcul de l'empreinte. Pour information, SHA-512 utilise la longueur sur 128bits, MD5 sur 64. 5) Pourquoi la taille de l'empreinte est importante? À cause du paradoxe des anniversaires, on peut montrer que trouver une collision ne nécessite pas autant de tentatives qu'on peut le penser intuitivement. Pour un haché de 64 bits, il faut 2^(64/2+1) calculs de haché pour en trouver une. Dans ces conditions, avoir un haché de 512 bits apporte plus de sécurité sur la résistance aux collisions. Fonctionnement : 1) Quel est le schéma permettant à une fonction de hachage de traiter un long message? Revoir le cours. En résumé : découpage du message en n blocs de

longueur fixée par l'algorithme. Eventuellement du padding à la fin. On injecte ces blocs dans une fonction de compression. 2) Comment est initialisé une fonction de hachage? On utilise un IV comme première valeur dans le schéma précédent. Cet IV est généralement fixé par l'algorithme (par exemple pour MD5 on utilise des constantes basées sur des sinus d'entiers). 3) Qu'est-ce qu'une fonction de compression? Une fonction de compression prend en entrée généralement deux messages de taille fixé, et produit un message de taille fixé. Une telle fonction est enchainée sur les différents blocs composants un message pour produire l'empreinte. Ces fonctions sont constituées de différents algorithmes propageant toute modification de l'entrée sur l'ensemble de la sortie. 4) On dispose d'une fonction de hachage résistante aux collisions, dont la taille des sortie est fixée. Est-ce que pour tout messages distincts M et M', on a deux haché distinct h=h(m) et h'=h(m')? Si la taille de l'empreinte est fixée pour tout les message, il y aura nécessairement des collisions (une fonction de hachage n'est jamais injective). L'important est que trouver une telle collision est irréalisable pour assurer la sécurité de la fonction de hachage. 5) Si on calcule deux fois d'affilé l'empreinte d'un même message, qu'obtient-on? En quoi est-ce important? La même empreinte. C'est un aspect important des fonctions de hachage. Cela permet de traiter l'empreinte comme si on traitait le message initial, par exemple dans les problèmes d'authenticité (signature). Utilisation pratique : I) Gestion des mots de passe II) Chiffrement

I) Gestion de mots de passes On utilise un système d'authentification basé sur des couples nom d'utilisateurmot de passe. On conserve quelque part une liste avec l'ensemble des noms d'utilisateurs et le mot de passe associé. Pour assurer un minimum de sécurité, on ne conserve pas tels quels les mots de passe, mais on conserve leur empreinte, obtenue avec une fonction de hachage. ==Q1== Dans le cas d'un client cherchant à s'identifier auprès du système, quels informations doit-il envoyer pour cela? Décrire le protocole entre les deux. Le client doit envoyer son nom et son mot de passe. Il est possible d'envoyer soit le mot de passe, soit directement son haché dans le protocole d'échange. Cela dit, l'envoi du haché évite la divulgation du mot de passe, et est préférable. ==Q2== Pourquoi conserver l'empreinte du mot de passe au lieu de son original? Un mot de passe ne devrait jamais être conservé, car en cas de corruption de la sécurité du système, cela dévoilerait le mot de passe. ==Q3== Quels problèmes peuvent se poser, si deux utilisateurs utilisent le même mot de passe? Et en cas de compromission de la liste des utilisateurs? En utilisant le même mot de passe dans ce système, on obtient le même haché. Cela peut poser un problème de sécurité en cas d'accès à la liste. En effet si cette liste est compromise, on peut découvrir si plusieurs utilisateurs utilisent le même mot de passe. Cette information seule peut amener à trouver le mot de passe d'un utilisateur en connaissant celui d'un autre utilisateur moins prudent. Par ailleurs, ce genre de système est vulnérable aux «tables arc-en-ciels» (rainbow tables). Ce sont des tables contenant les haché pré-calculés pour un grand nombre de valeurs (par exemple, les mots les plus courants d'un dictionnaire). À partir de ces tables, on peut retrouver très rapidement un mot de passe caché derrière une empreinte. On cherche à améliorer le système en utilisant un «sel». Cela consiste à hacher non pas le mot de passe, mais la concaténation du mot de passe et d'un élément aléatoire, appelé le sel. Ce dernier est stocké avec la liste des utilisateurs, et est différent pour chaque utilisateur. ==Q4== Pourquoi cela améliore la sécurité du système? L'utilisation d'un «sel» de taille raisonnable fait qu'utiliser les rainbow tables n'est plus envisageables : par exemple, il faudrait conserver l'empreinte d'un mot, et de toutes les variations du sel. Pour un sel de 32 bits, ça voudrait dire 2^32=+ de 4 milliards. Par ailleurs, un sel différent par utilisateur signifie que deux utilisateurs utilisant le même sel n'ont plus la même empreinte dans la liste. Cela «casse» ce lien. Par ailleurs, si un utilisateur utilise le même mot de passe sur plusieurs systèmes séparés, il n'est pas possible de savoir que c'est le cas juste en observant les empreintes. ==Q5== Le protocole précédent est-il toujours utilisable? Si non, comment

doit-il être modifié? Si on envoie l'empreinte du mot de passe, il n'est plus possible de calculer son empreinte «salée» à partir de ça. En effet, on reçoit H(M). Il faudrait calculer H(M S) (S étant le sel), mais on ne dispose pas de M. Il faut alors envoyer le sel à l'utilisateur, qui calculera lui même H(M S). ==Q6== Comment détermine-t-on le sel? Le sel peut être entièrement aléatoire. Dans ce cas, il faut utiliser un générateur aléatoire sur. Dans certaines applications on utilise une information de l'utilisateur (par exemple son nom) comme base pour ce sel. Cependant cela réduit son efficacité ; en effet, on se retrouve alors non plus avec (par exemple) 2^32 possibilités, puisque le sel doit avoir un sens.

II) Chiffrement Deux personnes veulent s'échanger un fichier de 50 gigaoctets. Pour cela, elles se mettent d'accord sur un mot de passe, et décident d'envoyer ce fichier par internet. Cependant, son contenu est sensible et ne doit pas pouvoir être intercepté. ==Q1== Comment peut-on assurer que le fichier ne sera pas lu par des tiers non autorisé? On utilise du chiffrement symétrique. Le chiffrement asymétrique n'est pas envisageable sur une telle taille. ==Q2== Si on décide d'utiliser du chiffrement symétrique, comment peut-on utiliser le mot de passe? Pourquoi? On utilise une PBKDF, qui permet de dériver une clé symétrique de taille fixe adaptée à l'algorithme choisi. Il existe aussi des KDF, moins adaptés à un mot de passe provenant d'un utilisateur. On doit passer par cette fonction, car le mot de passe seul n'a que rarement la bonne taille, et un mot de passe «humain» n'apporte pas une répartition apparemment aléatoire, car ce dernier n'utilise pas l'ensemble des possibilités de l'alphabet «numérique» (8bits par octets) ==Q3== Décrire l'ensemble du protocole permettant l'échange de ce fichier, à partir du mot de passe. Après l'échange du mot de passe «à la main» : A génère une clé secrète à partir du mot de passe et d'un sel aléatoire. Il chiffre le fichier, et envoi le chiffré avec le sel. B génère aussi la clé, à partir du mot de passe et du sel reçu. Il peut alors déchiffrer le fichier. Supposons maintenant qu'on envois deux autres fichiers, avec le même mot de passe. L'un des fichiers échangé se trouve compromis, et la clé de chiffrement est retrouvée. ==Q4== Quel problème cette compromission pose pour les deux autres fichiers? Comment éviter cela? Si on utilise le même sel à chaque fois, on obtient la même clé secrète. La compromission de la clé d'un fichier permet donc de retrouver le contenu de tout les fichiers. Si on utilise un sel différent, à partir du même mot de passe, on génère des clés secrètes différentes. Dans ces conditions, la compromission d'une des clés ne compromet pas les autres, malgré l'utilisation d'un unique mot de passe pour les trois fichiers.