Discussion :

[Sergejack]

J'ai beaucoup lu et entendu que le MD5 n'était plus sûr, qu'il était par exemple devenu facile de créer des collisions (différents messages avec le même hash).
Mais j'ai encore bien du mal à comprendre les limites des méthodes permettant de se jouer du MD5.
En particulier j'aimerais savoir ceci :

Si j'ai un "sel" de 16 octet, 16 octets de data, que je fais le hash des 32 octets (sel + data) alors avec quelle facilité (dans quels délais) peut on trouver d'autres 16 octets de data pour que le hash des 32 octets (sel + autre data) donne le même hash ?

illustration du propos:

sel = 0x0123456789abcdef
data = 0x0000000000000001
hash = MD5 hash(0x0123456789abcdef0000000000000001)
new data = 0x????????????????

new data <> data
MD5 hash(0x0123456789abcdef????????????????) = MD5 hash(0x0123456789abcdef0000000000000001)

=> Combien de temps pour trouver "new data" ?

[DonQuiche]

Bonjour.

Je ne connais pas suffisamment le sujet pour te répondre avec certitude mais :

a) Un doute est-il de toute façon acceptable ?

b) Si je ne m'abuse les collisions sont créées en partant d'une base connue pour donner le bon hash. Par exemple, partant d'un fichier connu pour avoir le hash requis on peut l'altérer pour y introduire un virus tout en conservant le même hash.

c) Ces méthodes ont été appliquées à de petits et gros fichiers (parfois en Go), auxquels ont été ajoutés des virus de plusieurs Mo, si bien que la taille des données initiales ou modifiées ne semble pas limitative. En revanche il faut a priori disposer d'une entrée donnant le hash désiré mais si j'ai raison la méthode rend possible l'utilisation d'une table à partir de laquelle on extraira une base compatible à laquelle on concaténera les données nécessaires.

[TropMDR]

Reponse courte: MD5 n'est plus du tout sur, ne l'utilise pas dans de nouvelles applications.

Reponse longue:

Il y a deux categories d'attaques contre un hash cryptographique: collision et pre-image. Collision: trouver deux messages differents avec le meme hash. Preimage: etant donne un hash, trouver un message ayant ce hash.

Dans le cas de MD5, il y a de nombreuses methodes pour obtenir des collisions, mais pour l'instant, il resiste toujours aux attaques pre-images. Donc dans ton cas, ca depend: est ce que l'attaquant controle juste "new data", ou aussi "data"?

Mais dans tous les cas, tu ne devrais pas utiliser MD5 (et sans doute pas non plus sha1). Qu'est ce que tu essayes de faire exactement?

[Invité]

Pour le hashage de mots de passe ou bien de clés dans une bases de données ou bien dans un fichier sha256 je pense que ça peut aller non ? (Sinon qu'est ce qui serait le mieux pour le hashage ?)
md5 c'est assez ancien et plus très sûr en effet.

Sinon moi pour le hashage de clés et mots de passe j'utilse sha256 et pour le transfert de données j'utilise rsa et l'aes256.

[TropMDR]

Utiliser MD5 pour hacher des mots de passes est une terrible idee, ainsi que SHA256. Il faut utiliser bcrypt, scrypt ou PBKDF2, qui rendent les attaques beaucoup plus difficiles.

[Invité]

Ok, ok merci.

[Sergejack]

Reponse courte: MD5 n'est plus du tout sur, ne l'utilise pas dans de nouvelles applications.

Reponse longue:

Il y a deux categories d'attaques contre un hash cryptographique: collision et pre-image. Collision: trouver deux messages differents avec le meme hash. Preimage: etant donne un hash, trouver un message ayant ce hash.

Dans le cas de MD5, il y a de nombreuses methodes pour obtenir des collisions, mais pour l'instant, il resiste toujours aux attaques pre-images. Donc dans ton cas, ca depend: est ce que l'attaquant controle juste "new data", ou aussi "data"?

Mais dans tous les cas, tu ne devrais pas utiliser MD5 (et sans doute pas non plus sha1). Qu'est ce que tu essayes de faire exactement?

Je veux juste envoyé une sorte de clé à un utilisateur, l"utilisateur de son côté génère un message.
Ensuite l'utilisateur m'envoie le MD5(clé + message).
Et enfin, l'utilisateur envoi son message que je peux alors vérifier.

[TropMDR]

C'est encore pire que ce que je pensais. La, tu es en train de tenter d'inventer un protocol crypto. Tu ne serais pas en train de faire du HMAC de tres mauvaise qualite? (http://en.wikipedia.org/wiki/Hash-ba...ntication_code)

[Sergejack]

Je en connaissais pas le HMAC, mais le concept est le même.

En quoi est-ce cependant de mauvaise qualité ?

Est-ce que concaténé une clé en début de message rend le MD5 du tout plus faible ?

[GeoffreyOnRails]

De manière générale, en cryptographie,on ne réimplante jamais soi-même les protocoles. Il existe tout un tas d'attaques qui ne sont pas liées à l'algorithme en lui-même mais à la façon dont il est implémenté. Cela va de l'erreur d'implémentation un peu bête à la heartbleed aux attaques sophistiquées en comptant le temps mis par l'implémentation de algorithme pour en déduire le nombre de cycles CPU utilisés afin de trouver des indices sur le mot de passe utilisé qui permettront de...

C'est pourquoi on utilise toujours des implémentations fiables, sur lesquelles un certain nombre de spécialistes (doctorants/chercheurs) de ces algorithmes ont planché. Ça et aussi afin d'éviter de perdre son temps en réinventant la roue.

Le seul cas où implémenter ton propre protocole a de l'intérêt est selon moi celui de l'apprentissage. C'est un bon exercice, ça assure qu'on a bien compris ce qu'il se passait.

[Sergejack]

Et comment je fais pour trouver si un protocole existe ?

Je me vois mal décrire ma situation au complet dans la barre de recherche google et obtenir un résultat significatif.

[GeoffreyOnRails]

Si google n'est pas ton ami, tu peux toujours poser la question ici. Si c'est un simple système d'authentification par mot de passe avec un sel, je pense que ça a déjà été codé de nombreuses fois et dans de nombreux langages. Si ton besoin est plus exotique, il va falloir donner des détails.

Quel est ton besoin fonctionnel? Contre quoi veux tu te prémunir?

[Sergejack]

Je veux que 2 utilisateurs s'échangent des valeurs aléatoires (1 par utilisateurs).
Ces valeurs aléatoires sont alors réunies en une seule qui servira dans un jeu (et peut avantager un utilisateur au détriment de l'autre).
Je veux empêcher 1 utilisateur d'attendre de recevoir la valeur de l'autre utilisateur et ensuite adapter la valeur qu'il envoi lui-même à l'autre.
Donc, je veux qu'il y ait d'abord un échange d'un élément qui, sans indiquer quelle est la valeur, permet de vérifier que la valeur reçue par la suite est bien l'originale.

[GeoffreyOnRails]

La première question que je me pose est : à quel point est-ce grave/probable qu'un joueur bidouille le code et triche?
Peu importe, voici les deux propositions que j'aurais :

Proposition 1 :
- les joueurs envoient en premier message un hash(sel+data) et le sel à côté.
- une fois le message de l'autre joueur reçu ils envoient les data.
Aucun besoin de s'embêter avec une clé si on ne peut pas créer de collisions. Pour la fonction de hash, sha256 ou sha512 n'ont pas de vulnérabilité connues aux collisions, autant les utiliser.

Proposition 2 (sans crypto) :
-Si tu as un système centralisé avec lequel le jeu communique pour envoyer des infos, et que celui-ci est capable de tenir la charge, il pourrait éventuellement servir de tiers de confiance. Il reçoit les données des joueurs et les envoie une fois qu'il les a toutes.

[vinceom92]

Dites-moi si je me trompe mais je pense que le md5 n'est plus à utiliser du fait des rainbows tables. Il est préférable d'utiliser sha1 pour le remplacer je crois.
De plus, il faut utiliser la technique du grain de sel.

Une question : Que différencie sha1 et sha256 ?

[TropMDR]

Avant de trouver une bonne solution, j'ai quelques questions:

1. Tu dis que les joueurs echangent des valeurs aleatoires. Est ce qu'elles doivent vraiment etre aleatoire, ou c'est OK si un joueur choisit ses valeurs tant qu'il ne connait pas celles de l'autre?
2. Pour chaque valeur echange, quelle est la taille de l'espace des valeurs possibles? Est ce que c'est 2^128 ou 6?
3. Pour chaque valeur, est ce que la taille (disons en octet) est fixe, ou est ce qu'elle peut etre variable?

[Sergejack]

Avant de trouver une bonne solution, j'ai quelques questions:

1. Tu dis que les joueurs echangent des valeurs aleatoires. Est ce qu'elles doivent vraiment etre aleatoire, ou c'est OK si un joueur choisit ses valeurs tant qu'il ne connait pas celles de l'autre?
2. Pour chaque valeur echange, quelle est la taille de l'espace des valeurs possibles? Est ce que c'est 2^128 ou 6?
3. Pour chaque valeur, est ce que la taille (disons en octet) est fixe, ou est ce qu'elle peut etre variable?

[*]Elles sont censées être aléatoire mais on n'a pas de contrôle certain là dessus (si le joueur est un hackeur, il envoie ce qu'il veut).[*]Je ne comprends pas la question. Je pense que chaque valeur à envoyé sera de 16 octet, la taille du hash serait de 16octets aussi si j'utilise MD5.[*]Fixe.

[TropMDR]

Si les valeurs doivent être aléatoires et non pas être choisie, tu devrais utiliser ton protocole d'échange pour passer deux graines pour un générateur aléatoire, les "mélanger", et tirer tes valeurs de ça. Si tu mets en place un protocole d'échange, c'est que tu t'attends a ce qu'il y ai un "hackeur"!

Je vais tenter de reformuler la question sur la taille de l'espace. La propriété d'une bonne fonction de hachage n'est pas "étant donné le hash d'une valeur, il est impossible de trouver la valeur" mais "trouver la valeur est aussi difficile qu'énumérer toutes les valeurs possibles, prendre leur hash, et le comparer".
Pour illustrer mon propos, supposons qu'un général disent "on va attaquer la semaine prochaine, je sais déjà quel jour, mais je vous le dirait plus tard. En attendant, voici mon sel: 4092CC8893A36F401F490, et concatene avec le jour de la semaine (sel + message), le sha1 est F2ED81FDA7809873F2A26590D183D7AC31C783F6". Ceci est la solution proposée par @GeoffreyOnRails.
Est ce que la solution est sûre? Un attaquant a juste a enumérer les jours de la semaine!
sha1(4092CC8893A36F401F490lundi) -> C228C6D68A73B4EB536516A26FE06E10B30E9300
sha1(4092CC8893A36F401F490mardi) -> 37E626292916688717665530095F10DAF5A1EF8E
sha1(4092CC8893A36F401F490mercredi) -> F2ED81FDA7809873F2A26590D183D7AC31C783F6 BINGO
L'attaque aura lieu mercredi!
A chaque fois que quelqu'un vous dit "il n'y a pas de risque, l'information est hachée!", il faut toujours se demander qu'elle est la taille de l'espace des valeurs. Par exemple si quelqu'un dit "on garde les adresses IP, mais hachées, donc pas de risque pour la vie privée", c'est un mensonge: énumérer 2^32 adresse est triviale. Pareil pour des numéro de téléphone, les noms, etc.

Donc dans le cas de ton protocole d'echange, il faut rendre l'espace plus grand en ajoutant une valeur aléatoire, mais il ne faut surtout pas la révéler avant de révéler aussi la valeur.

Maintenant, pourquoi la taille est-elle important? Supposons que tu aies voulu échanger une chaine de caractère, et que le nombre de A soit la chose importante, et que le protocole est de donner sha1(valeur + random), puis de reveler valeur et random. On commence l'échange, je te donne mon hash: 82E757683DB0B0417976C1661F7B020AE5225B80. Tu fais pareil, puis tu me donne ta valeur. La je décide que je devrais avoir 5 A. Donc je te dis: ma valeur est "AAAAA" et la partie aléatoire est "AAAAAAAAAAAAAAAAAAAAAA".
Supposons maintenant que tu me donnes une autre valeur, et que je decide a la place que je veux avoir 10 A. Je te dis que ma valeur est "AAAAAAAAAA" et ma partie aléatoire est "AAAAAAAAAAAAAAAAA". Et voilà, meme hash, deux valeurs différentes!
Les deux solutions pour ca sont:

1. Echanger hash(longeur+message+aleat), puis reveler les trois morceaux et les vérifier
2. utiliser un HMAC qui est déjà protégé contre ca

[Sergejack]

Mes valeurs échangées font 16 octets donc 2^128 bits, j'imagine que ce n'est plus trivial.

[DonQuiche]

Une question : Que différencie sha1 et sha256 ?

A peu près tout : ce n'est pas le même algorithme (même s'ils ont des points communs) et pas la même taille de clé. Sha256, 512 et suivants correspondent à sha-2, qui est la 3ème version de l'algorithme. Il est vraisemblable que sha1 est aussi vulnérable aux attaques par collision.

Mes valeurs échangées font 16 octets donc 2^128 bits, j'imagine que ce n'est plus trivial.

Oui mais est-ce réellement la taille de l'espace des valeurs ? Un code entre 0 et 3 occupera souvent 4 octets dans le flux mais l'espace des valeurs correspondant ne fait réellement que 2 bits. Si tu parles de tes clés aléatoires alors, oui, elles occupent bien tout l'espace.

Je veux empêcher 1 utilisateur d'attendre de recevoir la valeur de l'autre utilisateur et ensuite adapter la valeur qu'il envoi lui-même à l'autre.

Un système de clés asymétriques : par principe ces algorithmes sont faits pour rendre difficile l'obtention ou la falsification de la clé privée depuis une clé publique.

* A et B forgent chacun de leur côté une paire de clés.
* A et B s'échangent leurs clés publiques et conviennent de les utiliser.
* Une fois l'accord conclu, A et B fournissent les clés privées correspondantes et ils vérifient qu'elles correspondent aux clés publiques.
* En les concaténant ils obtiennent une clé qu'aucun d'entre ne pouvait anticiper dans sa globalité, quel que soit l'ordre de la transaction.
* Puis on obtient des valeurs aléatoires en hachant :
** r0 = sha512(concaténer(Xprivé, Yprivé))
** r[i+1] = sha512(r[i])

Si l'utilisation de sha512 pour chaque "jet de dé" pose un problème de performances alors on peut simplement générer r0, tronquer à la taille désirée et l'utiliser comme graine pour un générateur aléatoire non-cryptographique. Note que l'utilisation d'un hash pour r0 reste obligatoire pour évier qu'un des joueurs tire partie d'une faiblesse d'un générateur aléatoire non-cryptographique via sa moitié de bits de la clé.