[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: md5sum et CD



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 debian-french-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

-- 
Nicolas SABOURET
LIMSI-CNRS, BP133, 91403 Orsay, France
http://www.limsi.fr/Individu/nico



Reply to: