j'ai bien trouvé sur internet un machin pour coder le md5 mais par contre,
rien pour décoder ?
quel est l'intérêt supplémentaire d'avoir un truc qui ne marche que dans un
sens ?
comment faire pour une personne A pour envoyer un message md5 que seule une
personne B pourra décoder ?
comment ajouter un modérateur C entre A et B via md5?
comment faire pour une personne A pour envoyer un message md5 que seule une personne B pourra décoder ?
GPG ?
R.I.P
Guillermito
On 17 May 2004 16:07:49 GMT, Eric CHAPUZOT wrote:
quel est l'intérêt supplémentaire d'avoir un truc qui ne marche que dans un sens ?
C'est justement l'intérêt principal: avoir un chiffre unique, de taille fixe, une sorte d'empreinte (un hash), pour un fichier donné. Une empreinte suffisamment solide, unique et non réversible, pour que l'on ne puisse pas:
- trouver un fichier qui a une empreinte fixée à l'avance.
- trouver deux fichiers qui ont la même empreinte.
Avec d'autres algorithmes de somme de contrôle moins sûrs (un CRC par exemple), ces deux choses sont possibles. Mais les CRC ne sont pas utilisés dans des buts cryptographiques, plutôt comme sommes de contrôles rapide, pour détecter les erreurs de transmission par exemple.
Je vous renvoie à une introduction aux hashs / signatures électroniques ici:
Sinon, pour avoir de l'info en français, entrer "MD5 hachage" dans Google, par exemple. A noter aussi que le MD5 n'est qu'un algo de hash parmi tant d'autres.
-- Guillermito http://www.guillermito2.net
On 17 May 2004 16:07:49 GMT, Eric CHAPUZOT wrote:
quel est l'intérêt supplémentaire d'avoir un truc qui ne marche que dans un
sens ?
C'est justement l'intérêt principal: avoir un chiffre unique, de taille
fixe, une sorte d'empreinte (un hash), pour un fichier donné. Une
empreinte suffisamment solide, unique et non réversible, pour que l'on
ne puisse pas:
- trouver un fichier qui a une empreinte fixée à l'avance.
- trouver deux fichiers qui ont la même empreinte.
Avec d'autres algorithmes de somme de contrôle moins sûrs (un CRC par
exemple), ces deux choses sont possibles. Mais les CRC ne sont pas
utilisés dans des buts cryptographiques, plutôt comme sommes de
contrôles rapide, pour détecter les erreurs de transmission par exemple.
Je vous renvoie à une introduction aux hashs / signatures électroniques
ici:
Sinon, pour avoir de l'info en français, entrer "MD5 hachage" dans
Google, par exemple. A noter aussi que le MD5 n'est qu'un algo de hash
parmi tant d'autres.
quel est l'intérêt supplémentaire d'avoir un truc qui ne marche que dans un sens ?
C'est justement l'intérêt principal: avoir un chiffre unique, de taille fixe, une sorte d'empreinte (un hash), pour un fichier donné. Une empreinte suffisamment solide, unique et non réversible, pour que l'on ne puisse pas:
- trouver un fichier qui a une empreinte fixée à l'avance.
- trouver deux fichiers qui ont la même empreinte.
Avec d'autres algorithmes de somme de contrôle moins sûrs (un CRC par exemple), ces deux choses sont possibles. Mais les CRC ne sont pas utilisés dans des buts cryptographiques, plutôt comme sommes de contrôles rapide, pour détecter les erreurs de transmission par exemple.
Je vous renvoie à une introduction aux hashs / signatures électroniques ici:
Sinon, pour avoir de l'info en français, entrer "MD5 hachage" dans Google, par exemple. A noter aussi que le MD5 n'est qu'un algo de hash parmi tant d'autres.
-- Guillermito http://www.guillermito2.net
Nicob
On Mon, 17 May 2004 16:07:49 +0000, Eric CHAPUZOT wrote:
quel est l'intérêt supplémentaire d'avoir un truc qui ne marche que dans un sens ?
Le même que celui qui fait utiliser crypt() pour stocker les mots de passe dans /etc/shadow sous Unix.
comment faire pour une personne A pour envoyer un message md5 que seule une personne B pourra décoder ?
MD5 n'est pas un algo destiné à cet usage ...
Nicob
On Mon, 17 May 2004 16:07:49 +0000, Eric CHAPUZOT wrote:
quel est l'intérêt supplémentaire d'avoir un truc qui ne marche que
dans un sens ?
Le même que celui qui fait utiliser crypt() pour stocker les mots de
passe dans /etc/shadow sous Unix.
comment faire pour une personne A pour envoyer un message md5 que seule
une personne B pourra décoder ?
On Mon, 17 May 2004 16:07:49 +0000, Eric CHAPUZOT wrote:
quel est l'intérêt supplémentaire d'avoir un truc qui ne marche que dans un sens ?
Le même que celui qui fait utiliser crypt() pour stocker les mots de passe dans /etc/shadow sous Unix.
comment faire pour une personne A pour envoyer un message md5 que seule une personne B pourra décoder ?
MD5 n'est pas un algo destiné à cet usage ...
Nicob
Jacques Caron
Salut,
On 17 May 2004 16:07:49 GMT, Eric CHAPUZOT wrote:
j'ai bien trouvé sur internet un machin pour coder le md5 mais par contre, rien pour décoder ?
Outre toutes les réponses qui ont pu t'être faites, tu peux déjà regarder un truc: quelle que soit la taille du fichier passé à MD5 (un octet ou un Go), le résultat fait toujours 16 octets! Il n'y donc rien à décoder, ce n'est qu'un CRC évolué.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On 17 May 2004 16:07:49 GMT, Eric CHAPUZOT <echap@evhr.net> wrote:
j'ai bien trouvé sur internet un machin pour coder le md5 mais par
contre, rien pour décoder ?
Outre toutes les réponses qui ont pu t'être faites, tu peux déjà regarder
un truc: quelle que soit la taille du fichier passé à MD5 (un octet ou un
Go), le résultat fait toujours 16 octets! Il n'y donc rien à décoder, ce
n'est qu'un CRC évolué.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
j'ai bien trouvé sur internet un machin pour coder le md5 mais par contre, rien pour décoder ?
Outre toutes les réponses qui ont pu t'être faites, tu peux déjà regarder un truc: quelle que soit la taille du fichier passé à MD5 (un octet ou un Go), le résultat fait toujours 16 octets! Il n'y donc rien à décoder, ce n'est qu'un CRC évolué.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Eric CHAPUZOT
- trouver un fichier qui a une empreinte fixée à l'avance.
- trouver deux fichiers qui ont la même empreinte.
ca me parait hautement improbable avec 16 octets qu'on ne tombe pas
plusieurs fois sur des fichiers différents mais ayant la même empreinte : j'imagine une boite ayant 256 programmes x (faits par) 256 programmeurs(ce qui est raisonnable)x 256 fichiers de dévellopement et données (ca inclus la notice faite 256 fois par la petite secrétaire écervelée)x 256 jours et déjà 4 de tes octets ont des chances d'être très fortement redondants... maintenant, t'y adjoint deux sommes de contrôle sur 2x6 octets, dont les chances de redondance seront précisément de 1/4 (=1/2x1/2), tu t'assures de trouver dans la production globale une dizaine de fichiers ayant même signature, même empreinte... donc tout au plus, ca réduit le champ d'investigation mais ca n'assure rien à grande échelle...
- trouver un fichier qui a une empreinte fixée à l'avance.
- trouver deux fichiers qui ont la même empreinte.
ca me parait hautement improbable avec 16 octets qu'on ne tombe pas
plusieurs fois sur des fichiers différents mais ayant la même empreinte :
j'imagine une boite ayant
256 programmes x (faits par) 256 programmeurs(ce qui est raisonnable)x 256
fichiers de dévellopement et données (ca inclus la notice faite 256 fois par
la petite secrétaire écervelée)x 256 jours
et déjà 4 de tes octets ont des chances d'être très fortement redondants...
maintenant, t'y adjoint deux sommes de contrôle sur 2x6 octets, dont les
chances de redondance seront précisément de 1/4 (=1/2x1/2), tu t'assures de
trouver dans la production globale une dizaine de fichiers ayant même
signature, même empreinte...
donc tout au plus, ca réduit le champ d'investigation mais ca n'assure rien
à grande échelle...
- trouver un fichier qui a une empreinte fixée à l'avance.
- trouver deux fichiers qui ont la même empreinte.
ca me parait hautement improbable avec 16 octets qu'on ne tombe pas
plusieurs fois sur des fichiers différents mais ayant la même empreinte : j'imagine une boite ayant 256 programmes x (faits par) 256 programmeurs(ce qui est raisonnable)x 256 fichiers de dévellopement et données (ca inclus la notice faite 256 fois par la petite secrétaire écervelée)x 256 jours et déjà 4 de tes octets ont des chances d'être très fortement redondants... maintenant, t'y adjoint deux sommes de contrôle sur 2x6 octets, dont les chances de redondance seront précisément de 1/4 (=1/2x1/2), tu t'assures de trouver dans la production globale une dizaine de fichiers ayant même signature, même empreinte... donc tout au plus, ca réduit le champ d'investigation mais ca n'assure rien à grande échelle...
Guillermito
On 17 May 2004 20:12:35 GMT, Eric CHAPUZOT wrote:
ca me parait hautement improbable avec 16 octets qu'on ne tombe pas plusieurs fois sur des fichiers différents mais ayant la même empreinte :
Vous devriez prendre une feuille, un crayon, et faire quelques calculs simples en puissances de 10. Vous verrez qu'il faut se méfier de l'intuition quand on manipule les grands chiffres.
En l'occurrence, c'est extrèmement improbable - on peut même raisonnablement dire qu'à l'échelle humaine, c'est impossible - de tomber sur la même empreinte par hasard.
j'imagine une boite ayant 256 programmes x (faits par) 256 programmeurs(ce qui est raisonnable)x 256 fichiers de dévellopement et données (ca inclus la notice faite 256 fois par la petite secrétaire écervelée)x 256 jours
- Espace du MD5:
2^128 possibilités = 3 10^38
- Nombre de possibilités imaginées par Eric Chapuzot dans l'exemple ci-dessus:
256^4 = 4 10^9
Le nombre de possibilités que vous imaginez est encore 100000000000000000000000000000 fois moins que le nombre de possibilités d'un MD5.
Il faut se méfier des exponentielles, et des grands nombres.
tu t'assures de trouver dans la production globale une dizaine de fichiers ayant même signature, même empreinte...
Faites donc le test. Utilisez votre générateur de mots de passe aléatoires pour créér une centaine de milliards de fichiers différents. Calculez leur MD5. Essayez de trouver deux MD5 égaux, sur deux fichiers différents. On attend les résultats.
-- Guillermito http://www.guillermito2.net
On 17 May 2004 20:12:35 GMT, Eric CHAPUZOT wrote:
ca me parait hautement improbable avec 16 octets qu'on ne tombe pas
plusieurs fois sur des fichiers différents mais ayant la même empreinte :
Vous devriez prendre une feuille, un crayon, et faire quelques calculs
simples en puissances de 10. Vous verrez qu'il faut se méfier de
l'intuition quand on manipule les grands chiffres.
En l'occurrence, c'est extrèmement improbable - on peut même
raisonnablement dire qu'à l'échelle humaine, c'est impossible - de
tomber sur la même empreinte par hasard.
j'imagine une boite ayant
256 programmes x (faits par) 256 programmeurs(ce qui est raisonnable)x 256
fichiers de dévellopement et données (ca inclus la notice faite 256 fois par
la petite secrétaire écervelée)x 256 jours
- Espace du MD5:
2^128 possibilités = 3 10^38
- Nombre de possibilités imaginées par Eric Chapuzot dans l'exemple
ci-dessus:
256^4 = 4 10^9
Le nombre de possibilités que vous imaginez est encore
100000000000000000000000000000 fois moins que le nombre de possibilités
d'un MD5.
Il faut se méfier des exponentielles, et des grands nombres.
tu t'assures de
trouver dans la production globale une dizaine de fichiers ayant même
signature, même empreinte...
Faites donc le test. Utilisez votre générateur de mots de passe
aléatoires pour créér une centaine de milliards de fichiers différents.
Calculez leur MD5. Essayez de trouver deux MD5 égaux, sur deux fichiers
différents. On attend les résultats.
ca me parait hautement improbable avec 16 octets qu'on ne tombe pas plusieurs fois sur des fichiers différents mais ayant la même empreinte :
Vous devriez prendre une feuille, un crayon, et faire quelques calculs simples en puissances de 10. Vous verrez qu'il faut se méfier de l'intuition quand on manipule les grands chiffres.
En l'occurrence, c'est extrèmement improbable - on peut même raisonnablement dire qu'à l'échelle humaine, c'est impossible - de tomber sur la même empreinte par hasard.
j'imagine une boite ayant 256 programmes x (faits par) 256 programmeurs(ce qui est raisonnable)x 256 fichiers de dévellopement et données (ca inclus la notice faite 256 fois par la petite secrétaire écervelée)x 256 jours
- Espace du MD5:
2^128 possibilités = 3 10^38
- Nombre de possibilités imaginées par Eric Chapuzot dans l'exemple ci-dessus:
256^4 = 4 10^9
Le nombre de possibilités que vous imaginez est encore 100000000000000000000000000000 fois moins que le nombre de possibilités d'un MD5.
Il faut se méfier des exponentielles, et des grands nombres.
tu t'assures de trouver dans la production globale une dizaine de fichiers ayant même signature, même empreinte...
Faites donc le test. Utilisez votre générateur de mots de passe aléatoires pour créér une centaine de milliards de fichiers différents. Calculez leur MD5. Essayez de trouver deux MD5 égaux, sur deux fichiers différents. On attend les résultats.
-- Guillermito http://www.guillermito2.net
Cedric Blancher
Le Mon, 17 May 2004 20:12:35 +0000, Eric CHAPUZOT a écrit :
- trouver deux fichiers qui ont la même empreinte. ca me parait hautement improbable avec 16 octets qu'on ne tombe pas
plusieurs fois sur des fichiers différents mais ayant la même empreinte [...]
donc tout au plus, ca réduit le champ d'investigation mais ca n'assure rien à grande échelle...
Tu as absolument raison. C'est complètement mathématique. L'espace de départ est infini (l'ensemble des messages) alors que l'espace d'arrivée est fini (ensemble de mots de 128 bits). Les collisions sont donc possibles.
Mais ce qui nous intéresse, ce n'est pas tant le fait que les collisions soient impossibles, mais plutôt qu'on ne puisse pas fabriquer un message qui aurait la même empreinte qu'un autre. En gros, j'ai A, et donc MD5(A), et je cherche B tel que MD5(B) = MD5(A) (ce que Guillermito appelle : "trouver un fichier qui a une empreinte fixée à l'avance"). Ce type de recherche ne semble pas possible en dehors de la recherche exhaustive, ce qui nous amène à un problème grosso modo équivalent à casser un clé de 128 bits en force brute, ce que des gens nettement plus compétents que moi sur fr.misc.cryptologie considèrent au delà des moyens technologiques (connus) disponibles aujourd'hui.
À partir de là, il est hautement improbable que quelqu'un puisse falsifier un message, donc en altérer le sens, tout en conservant la même l'empreinte. Et c'est précisément ce qui nous intéresse. De même, si on se sert d'un algorithme comme MD5 pour crypter un mot de passe, il est hautement improbable que deux mots de passe ait le même hash, d'autant que l'espace des mdp couramment utilisés (mettons tous les mdp de 1 à 12 caractères) a moins de membres qu'un espace de 128 bits. Et ceci est d'autant plus vrai que la fonction est extrêmement variable, à savoir que deux messages très proches auront des empreintes complètement différentes, ce qui peut laisser penser (raccourci rapide) que deux messages ayant le même hash soient tellement différent que la confusion ne soit même pas concevable.
-- Tu as une vision obsolète du Net. Les groupes sont hébergés chez les FAI maintenant. Il FAUT que leur gestion change. -+- Rocou in GNU : l'avenir appartient à ceux qui neuneutent tôt -+-
Le Mon, 17 May 2004 20:12:35 +0000, Eric CHAPUZOT a écrit :
- trouver deux fichiers qui ont la même empreinte.
ca me parait hautement improbable avec 16 octets qu'on ne tombe pas
plusieurs fois sur des fichiers différents mais ayant la même empreinte
[...]
donc tout au plus, ca réduit le champ d'investigation mais ca n'assure rien
à grande échelle...
Tu as absolument raison. C'est complètement mathématique. L'espace de
départ est infini (l'ensemble des messages) alors que l'espace d'arrivée
est fini (ensemble de mots de 128 bits). Les collisions sont donc
possibles.
Mais ce qui nous intéresse, ce n'est pas tant le fait que les collisions
soient impossibles, mais plutôt qu'on ne puisse pas fabriquer un message
qui aurait la même empreinte qu'un autre. En gros, j'ai A, et donc
MD5(A), et je cherche B tel que MD5(B) = MD5(A) (ce que Guillermito
appelle : "trouver un fichier qui a une empreinte fixée à l'avance"). Ce
type de recherche ne semble pas possible en dehors de la recherche
exhaustive, ce qui nous amène à un problème grosso modo équivalent à
casser un clé de 128 bits en force brute, ce que des gens nettement plus
compétents que moi sur fr.misc.cryptologie considèrent au delà des
moyens technologiques (connus) disponibles aujourd'hui.
À partir de là, il est hautement improbable que quelqu'un puisse
falsifier un message, donc en altérer le sens, tout en conservant la
même l'empreinte. Et c'est précisément ce qui nous intéresse. De
même, si on se sert d'un algorithme comme MD5 pour crypter un mot de
passe, il est hautement improbable que deux mots de passe ait le même
hash, d'autant que l'espace des mdp couramment utilisés (mettons tous les
mdp de 1 à 12 caractères) a moins de membres qu'un espace de 128 bits.
Et ceci est d'autant plus vrai que la fonction est extrêmement variable,
à savoir que deux messages très proches auront des empreintes
complètement différentes, ce qui peut laisser penser (raccourci rapide)
que deux messages ayant le même hash soient tellement différent que la
confusion ne soit même pas concevable.
--
Tu as une vision obsolète du Net. Les groupes sont hébergés chez les
FAI maintenant. Il FAUT que leur gestion change.
-+- Rocou in GNU : l'avenir appartient à ceux qui neuneutent tôt -+-
Le Mon, 17 May 2004 20:12:35 +0000, Eric CHAPUZOT a écrit :
- trouver deux fichiers qui ont la même empreinte. ca me parait hautement improbable avec 16 octets qu'on ne tombe pas
plusieurs fois sur des fichiers différents mais ayant la même empreinte [...]
donc tout au plus, ca réduit le champ d'investigation mais ca n'assure rien à grande échelle...
Tu as absolument raison. C'est complètement mathématique. L'espace de départ est infini (l'ensemble des messages) alors que l'espace d'arrivée est fini (ensemble de mots de 128 bits). Les collisions sont donc possibles.
Mais ce qui nous intéresse, ce n'est pas tant le fait que les collisions soient impossibles, mais plutôt qu'on ne puisse pas fabriquer un message qui aurait la même empreinte qu'un autre. En gros, j'ai A, et donc MD5(A), et je cherche B tel que MD5(B) = MD5(A) (ce que Guillermito appelle : "trouver un fichier qui a une empreinte fixée à l'avance"). Ce type de recherche ne semble pas possible en dehors de la recherche exhaustive, ce qui nous amène à un problème grosso modo équivalent à casser un clé de 128 bits en force brute, ce que des gens nettement plus compétents que moi sur fr.misc.cryptologie considèrent au delà des moyens technologiques (connus) disponibles aujourd'hui.
À partir de là, il est hautement improbable que quelqu'un puisse falsifier un message, donc en altérer le sens, tout en conservant la même l'empreinte. Et c'est précisément ce qui nous intéresse. De même, si on se sert d'un algorithme comme MD5 pour crypter un mot de passe, il est hautement improbable que deux mots de passe ait le même hash, d'autant que l'espace des mdp couramment utilisés (mettons tous les mdp de 1 à 12 caractères) a moins de membres qu'un espace de 128 bits. Et ceci est d'autant plus vrai que la fonction est extrêmement variable, à savoir que deux messages très proches auront des empreintes complètement différentes, ce qui peut laisser penser (raccourci rapide) que deux messages ayant le même hash soient tellement différent que la confusion ne soit même pas concevable.
-- Tu as une vision obsolète du Net. Les groupes sont hébergés chez les FAI maintenant. Il FAUT que leur gestion change. -+- Rocou in GNU : l'avenir appartient à ceux qui neuneutent tôt -+-
Thierry Boudet
On 2004-05-17, Eric CHAPUZOT wrote:
quel est l'intérêt supplémentaire d'avoir un truc qui ne marche que dans un sens ?
Je fait un fichier "toto" que je publie sur le serveur A je calcule la somme du fichier "toto" et je la met sur le serveur B
tu downloade le fichier de A, tu calcule chez toi sa somme md5, et tu la compare à celle lue dans le serveur B.
si ça concorde, tu es 'un peu plus' certain que le fichier est bon. sauf si les deux serveurs se sont fait craquer en même temps.
mais, bon, ce n'est qu'un exemple...
--
je veux installer un bsd mais je sais pas lequel ? quelles sont les différence entre net open free,bsd Aucunes differences, les trois sont base sur linux slackware.
On 2004-05-17, Eric CHAPUZOT <echap@evhr.net> wrote:
quel est l'intérêt supplémentaire d'avoir un truc qui ne marche que dans un
sens ?
Je fait un fichier "toto" que je publie sur le serveur A
je calcule la somme du fichier "toto" et je la met sur le serveur B
tu downloade le fichier de A, tu calcule chez toi sa somme md5,
et tu la compare à celle lue dans le serveur B.
si ça concorde, tu es 'un peu plus' certain que le fichier est
bon. sauf si les deux serveurs se sont fait craquer en même temps.
mais, bon, ce n'est qu'un exemple...
--
je veux installer un bsd mais je sais pas lequel ?
quelles sont les différence entre net open free,bsd
Aucunes differences, les trois sont base sur linux slackware.
quel est l'intérêt supplémentaire d'avoir un truc qui ne marche que dans un sens ?
Je fait un fichier "toto" que je publie sur le serveur A je calcule la somme du fichier "toto" et je la met sur le serveur B
tu downloade le fichier de A, tu calcule chez toi sa somme md5, et tu la compare à celle lue dans le serveur B.
si ça concorde, tu es 'un peu plus' certain que le fichier est bon. sauf si les deux serveurs se sont fait craquer en même temps.
mais, bon, ce n'est qu'un exemple...
--
je veux installer un bsd mais je sais pas lequel ? quelles sont les différence entre net open free,bsd Aucunes differences, les trois sont base sur linux slackware.
trouver dans la production globale une dizaine de fichiers ayant même
signature, même empreinte... donc tout au plus, ca réduit le champ d'investigation mais ca n'assure rien à grande échelle...
Mais ça aide bien quand même. Imagine un .tar.gz avec dedans une image .BMP 16 couleurs et 300 lignes de perl. Va produire ces deux choses, réalisant "en apparence" la même fonction, mais différentes de l'original (trojan, modification des données,...) donnant la même somme md5. C'est déja beaucoup plus délicat, non ?
--
je veux installer un bsd mais je sais pas lequel ? quelles sont les différence entre net open free,bsd Aucunes differences, les trois sont base sur linux slackware.
On 2004-05-17, Eric CHAPUZOT <echap@evhr.net> wrote:
trouver dans la production globale une dizaine de fichiers ayant même
signature, même empreinte...
donc tout au plus, ca réduit le champ d'investigation mais ca n'assure rien
à grande échelle...
Mais ça aide bien quand même. Imagine un .tar.gz avec dedans une
image .BMP 16 couleurs et 300 lignes de perl. Va produire ces deux
choses, réalisant "en apparence" la même fonction, mais différentes
de l'original (trojan, modification des données,...) donnant la
même somme md5. C'est déja beaucoup plus délicat, non ?
--
je veux installer un bsd mais je sais pas lequel ?
quelles sont les différence entre net open free,bsd
Aucunes differences, les trois sont base sur linux slackware.
trouver dans la production globale une dizaine de fichiers ayant même
signature, même empreinte... donc tout au plus, ca réduit le champ d'investigation mais ca n'assure rien à grande échelle...
Mais ça aide bien quand même. Imagine un .tar.gz avec dedans une image .BMP 16 couleurs et 300 lignes de perl. Va produire ces deux choses, réalisant "en apparence" la même fonction, mais différentes de l'original (trojan, modification des données,...) donnant la même somme md5. C'est déja beaucoup plus délicat, non ?
--
je veux installer un bsd mais je sais pas lequel ? quelles sont les différence entre net open free,bsd Aucunes differences, les trois sont base sur linux slackware.
