Effectivement, je n'avais pas �t� clair. L'utilisation de MD5 pour crypter les clefs m�rite une explication particuli�re, et celle de Patrick est tr�s claire.
Si tu (Patrick) le permet, j'y ajoute qqes remarques puis j'essaye de montrer la diff�rence avec un cryptage "classique". Concernant l'utilisation de MD5 pour passwd est la suivante : il est clair qu'il ne faut JAMAIS stocker un mot de passe en clair. C'est pourquoi, quand tu tapes ton "nouveau" mot de passe, on construit son digest (md5sum) et on ne garde QUE cela. Comme c'est irr�versible, c'est *sans danger*. Lorsque tu tapes ton passwd pour te loguer, c'est pareil : on construit le digest (on ne garde JAMAIS le passwd)... et on compare les deux digests :) La force de MD5 (et d'autres) est que pour les mots <128bits, clefs identiques => sources identiques, comme l'a expliqu� Patrick. Le cryptage, c'est un peu diff�rent : tu veux envoyer un message a qqun. Tu code ton messages selon un principe similaire, sauf que c'est r�versible (mais il faut une "clef"). Le protocole est donc diff�rent : - le message original est stock� en clair chez l'�metteur (ex: le code de ta carte bleue dans la puce *inviolable* (hum ...)) - l'emetteur et le r�cepteur se mettent d'accord sur des clefs de cryptage (en gros, une dans chaque sens) (ce qui est fort, c'est que si tu as la clef de codage, tu ne peux pas d�coder, mais bon, je ne vais pas expliquer ici (sauf si demande)) - le message est cod� en utilisant la clef donn�e par le r�cepteur - le message cod� est envoy� (ex: l'automate code ce que tu tapes sur le clavier et l'envoie � la carte) - le r�cepteur le d�code gr�ce � sa clef - le r�cepteur lit le message (ex: la carte v�rifie que tu ne t'es pas plant�) Voil�. J'esp�re que j'ai �t� clair et pas trop long. Nico. Patrick wrote: > > On Mon, Mar 05, 2001 at 11:18:15AM +0100, Nicolas SABOURET took time to write: > > Pour les suites de caract�res (nombres) assez courtes, une clef md5 est > > �quivalente � un cryptage. C'est pourquoi les passwd sont parfois > > encrypt�s en md5. > > [...] > > > 4. Elle peut �tre utilis�e pour crypter les mots de moins de 32 > > caract�res (je suis pas sur du 32, � v�rifier) > > Non, je ne dirai pas ca. Les digests (MD5, qui commence � �tre > remplac� maintenant par SHA-1 ou RIPEMD-160) ne sont pas utilis�s > pour crypter, justement parce qu'apr�s on ne peut pas d�crypter > (c'est non r�versible comme cela a �t� tr�s justement dit). > > Ils sont utilis�s pour avoir une indication (ie une s�quence) d�duite > � partir d'une s�quence initiale (mot de passe, fichier, etc...) mais > qui ne permet pas de remonter � la s�quence initiale. > > Ie, dans /etc/shadow on ne stocke pas le mot de passe en clair, mais > on stocke (maintenant, car avant c'�tait encore autre chose, et ca > utilisait DES), le digest MD5 du mot de passe en clair. > Ainsi, si quelqu'un r�cup�re cela, il ne peut pas (sauf attaque de > force ou exploitation des failles reconnues de MD5) retrouver la > chaine de caract�res initiale (le mot de passe). > D'un autre c�t�, maintenant, pour v�rifier que l'utilisateur a le bon > mot de passe, on lui demande le mot de passe, on refait la m�me op�ration > math�matique (ie on calcule le digest MD5), et on compare les deux > s�quences (celle calcul�e et celle stock�e) : si les deux chaines > sorties de MD5 sont identiques, la probabilit� que les deux chaines > initiales (les mots de passe) �taient identiques est ``presque'' de > 100% > Presque, parce que, quoi qu'il arrive, MD5 ne produit que 128 bits en > sortie. Et qu'il n'y a donc que 2^128 ``s�quences'' MD5 diff�rentes > possible. Et que donc il est _possible_ mais peu probable d'avoir > deux entr�es diff�rentes qui produisent le m�me digest MD5. > > -- > Patrick. > ``C'est un monde qui n'a pas les moyens de ne plus avoir mal.'' > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Nicolas SABOURET LIMSI-CNRS, BP133, 91403 Orsay, France http://www.limsi.fr/Individu/nico
