je suis à la recherche d'utilitaires (Linux ou Windows) permettant de : -découvrir l'algorithme utilisé -décrypter un fichier.
En résumé, je possède un fichier crypté que je souhaite décrypter.
Ben ça se fait pas comme ça. Moi, par exemple, je procède ainsi. J'amasse un maximum de renseignements sur le soft qui a servi a générer le fichier chiffré. Notamment, l'algorithme utilisé. Si c'est du lourd et pas cassable (RSA et ses amis), je bosse alors le logiciel pour voir s'il ne recèle pas une petite faille exploitable. Si l'algo n'est pas spécifié, tu peux toujours désassembler pour voir, mais, je ne te donne pas ce conseil car cela n'est pas autorisé chez nous.
Sinon, si on te file un simple fichier sans rien te dire, heu...
Bon, tu peux essayer tout un tas d'algos, rot13, Vigénère, etc. Avec de l'habitude, peut être peux-tu même "deviner", te faire une idée du type d'algo. Mais bon, les miracles, c'est au cinéma.
Merci pour toute information.
De rien.
-- AMcD®
http://arnold.mcdonald.free.fr/
Gaël wrote:
Bonjour,
Salut.
je suis à la recherche d'utilitaires (Linux ou Windows) permettant de
: -découvrir l'algorithme utilisé
-décrypter un fichier.
En résumé, je possède un fichier crypté que je souhaite décrypter.
Ben ça se fait pas comme ça. Moi, par exemple, je procède ainsi. J'amasse un
maximum de renseignements sur le soft qui a servi a générer le fichier
chiffré. Notamment, l'algorithme utilisé. Si c'est du lourd et pas cassable
(RSA et ses amis), je bosse alors le logiciel pour voir s'il ne recèle pas
une petite faille exploitable. Si l'algo n'est pas spécifié, tu peux
toujours désassembler pour voir, mais, je ne te donne pas ce conseil car
cela n'est pas autorisé chez nous.
Sinon, si on te file un simple fichier sans rien te dire, heu...
Bon, tu peux essayer tout un tas d'algos, rot13, Vigénère, etc. Avec de
l'habitude, peut être peux-tu même "deviner", te faire une idée du type
d'algo. Mais bon, les miracles, c'est au cinéma.
je suis à la recherche d'utilitaires (Linux ou Windows) permettant de : -découvrir l'algorithme utilisé -décrypter un fichier.
En résumé, je possède un fichier crypté que je souhaite décrypter.
Ben ça se fait pas comme ça. Moi, par exemple, je procède ainsi. J'amasse un maximum de renseignements sur le soft qui a servi a générer le fichier chiffré. Notamment, l'algorithme utilisé. Si c'est du lourd et pas cassable (RSA et ses amis), je bosse alors le logiciel pour voir s'il ne recèle pas une petite faille exploitable. Si l'algo n'est pas spécifié, tu peux toujours désassembler pour voir, mais, je ne te donne pas ce conseil car cela n'est pas autorisé chez nous.
Sinon, si on te file un simple fichier sans rien te dire, heu...
Bon, tu peux essayer tout un tas d'algos, rot13, Vigénère, etc. Avec de l'habitude, peut être peux-tu même "deviner", te faire une idée du type d'algo. Mais bon, les miracles, c'est au cinéma.
Merci pour toute information.
De rien.
-- AMcD®
http://arnold.mcdonald.free.fr/
Gaël
Gaël wrote:
Bonjour,
Salut.
je suis à la recherche d'utilitaires (Linux ou Windows) permettant de : -découvrir l'algorithme utilisé -décrypter un fichier.
En résumé, je possède un fichier crypté que je souhaite décrypter.
Ben ça se fait pas comme ça. Moi, par exemple, je procède ainsi. J'amasse un maximum de renseignements sur le soft qui a servi a générer le fichier chiffré. Notamment, l'algorithme utilisé. Si c'est du lourd et pas cassable (RSA et ses amis), je bosse alors le logiciel pour voir s'il ne recèle pas une petite faille exploitable. Si l'algo n'est pas spécifié, tu peux toujours désassembler pour voir, mais, je ne te donne pas ce conseil car cela n'est pas autorisé chez nous.
Sinon, si on te file un simple fichier sans rien te dire, heu...
Bon, tu peux essayer tout un tas d'algos, rot13, Vigénère, etc. Avec de l'habitude, peut être peux-tu même "deviner", te faire une idée du type d'algo. Mais bon, les miracles, c'est au cinéma.
Oui c'est exactement le cas, j'ai un fichier chiffré dont je ne connais rien.
A te lire on peut déduire que n'importe quel chiffrement, même le plus simple soit-il, est fiable s'il est "inconnu" ...
J'avoue que ça me laisse perplexe.
Je pensais, sans doute à tort, que des outils et un peu de méthode et du temps, suffisaient à casser la plus part des algorithmes.
Merci pour toute information.
De rien.
Gaël wrote:
Bonjour,
Salut.
je suis à la recherche d'utilitaires (Linux ou Windows) permettant de
: -découvrir l'algorithme utilisé
-décrypter un fichier.
En résumé, je possède un fichier crypté que je souhaite décrypter.
Ben ça se fait pas comme ça. Moi, par exemple, je procède ainsi. J'amasse un
maximum de renseignements sur le soft qui a servi a générer le fichier
chiffré. Notamment, l'algorithme utilisé. Si c'est du lourd et pas cassable
(RSA et ses amis), je bosse alors le logiciel pour voir s'il ne recèle pas
une petite faille exploitable. Si l'algo n'est pas spécifié, tu peux
toujours désassembler pour voir, mais, je ne te donne pas ce conseil car
cela n'est pas autorisé chez nous.
Sinon, si on te file un simple fichier sans rien te dire, heu...
Bon, tu peux essayer tout un tas d'algos, rot13, Vigénère, etc. Avec de
l'habitude, peut être peux-tu même "deviner", te faire une idée du type
d'algo. Mais bon, les miracles, c'est au cinéma.
Oui c'est exactement le cas, j'ai un fichier chiffré dont je ne connais
rien.
A te lire on peut déduire que n'importe quel chiffrement, même le plus
simple soit-il, est fiable s'il est "inconnu" ...
J'avoue que ça me laisse perplexe.
Je pensais, sans doute à tort, que des outils et un peu de méthode et du
temps, suffisaient à casser la plus part des algorithmes.
je suis à la recherche d'utilitaires (Linux ou Windows) permettant de : -découvrir l'algorithme utilisé -décrypter un fichier.
En résumé, je possède un fichier crypté que je souhaite décrypter.
Ben ça se fait pas comme ça. Moi, par exemple, je procède ainsi. J'amasse un maximum de renseignements sur le soft qui a servi a générer le fichier chiffré. Notamment, l'algorithme utilisé. Si c'est du lourd et pas cassable (RSA et ses amis), je bosse alors le logiciel pour voir s'il ne recèle pas une petite faille exploitable. Si l'algo n'est pas spécifié, tu peux toujours désassembler pour voir, mais, je ne te donne pas ce conseil car cela n'est pas autorisé chez nous.
Sinon, si on te file un simple fichier sans rien te dire, heu...
Bon, tu peux essayer tout un tas d'algos, rot13, Vigénère, etc. Avec de l'habitude, peut être peux-tu même "deviner", te faire une idée du type d'algo. Mais bon, les miracles, c'est au cinéma.
Oui c'est exactement le cas, j'ai un fichier chiffré dont je ne connais rien.
A te lire on peut déduire que n'importe quel chiffrement, même le plus simple soit-il, est fiable s'il est "inconnu" ...
J'avoue que ça me laisse perplexe.
Je pensais, sans doute à tort, que des outils et un peu de méthode et du temps, suffisaient à casser la plus part des algorithmes.
Merci pour toute information.
De rien.
AMcD®
Gaël wrote:
Oui c'est exactement le cas, j'ai un fichier chiffré dont je ne connais rien.
Bon courage.
A te lire on peut déduire que n'importe quel chiffrement, même le plus simple soit-il, est fiable s'il est "inconnu" ...
Je n'ai jamais dit cela. Tu peux essayer divers algorithmes de substitutions, diverses méthodes "classiques", etc. Tout dépend d'où provient ton fichier chiffré. Application ultra-sécurisée ? Jeu ? Défi ? Les niveaux de cryptographie diffèreront suivant les besoins et le niveau que requérait l'application qui l'a généré.
J'avoue que ça me laisse perplexe.
Si t'as aucune piste, c'est difficile de trouver. Si je te dis voici un cryptogramme, 1A75 F6AZ, qui contient un mot caché sans rien te dire d'autre, comment veux-tu le retrouver ? Tu vas essayer quelques algorithmes classiques, mais bon, cela relève du miracle et de la grosse chance. Tout dépend aussi de la longueur du cryptogramme. Celui-ci est trop court pour pouvoir tenter ne serait-ce qu'une analyse de fréquence.
Je pensais, sans doute à tort, que des outils et un peu de méthode et du temps, suffisaient à casser la plus part des algorithmes.
Non, ça, c'est à la télé... Si ton application utilise une méthode sûre, déjà, à la base, c'est incassable, même si tu connais l'algorithme. Alors, si en plus tu connais même pas l'algo et que le gars à fait du RSA ou d'autres trucs aussi comiques, tu peux aller te pendre... Bon, maintenant, c'est peut-être aussi simplement un XOR ou un rot13 hein...
-- AMcD®
http://arnold.mcdonald.free.fr/
Gaël wrote:
Oui c'est exactement le cas, j'ai un fichier chiffré dont je ne
connais rien.
Bon courage.
A te lire on peut déduire que n'importe quel chiffrement, même le plus
simple soit-il, est fiable s'il est "inconnu" ...
Je n'ai jamais dit cela. Tu peux essayer divers algorithmes de
substitutions, diverses méthodes "classiques", etc. Tout dépend d'où
provient ton fichier chiffré. Application ultra-sécurisée ? Jeu ? Défi ? Les
niveaux de cryptographie diffèreront suivant les besoins et le niveau que
requérait l'application qui l'a généré.
J'avoue que ça me laisse perplexe.
Si t'as aucune piste, c'est difficile de trouver. Si je te dis voici un
cryptogramme, 1A75 F6AZ, qui contient un mot caché sans rien te dire
d'autre, comment veux-tu le retrouver ? Tu vas essayer quelques algorithmes
classiques, mais bon, cela relève du miracle et de la grosse chance. Tout
dépend aussi de la longueur du cryptogramme. Celui-ci est trop court pour
pouvoir tenter ne serait-ce qu'une analyse de fréquence.
Je pensais, sans doute à tort, que des outils et un peu de méthode et
du temps, suffisaient à casser la plus part des algorithmes.
Non, ça, c'est à la télé... Si ton application utilise une méthode sûre,
déjà, à la base, c'est incassable, même si tu connais l'algorithme. Alors,
si en plus tu connais même pas l'algo et que le gars à fait du RSA ou
d'autres trucs aussi comiques, tu peux aller te pendre... Bon, maintenant,
c'est peut-être aussi simplement un XOR ou un rot13 hein...
Oui c'est exactement le cas, j'ai un fichier chiffré dont je ne connais rien.
Bon courage.
A te lire on peut déduire que n'importe quel chiffrement, même le plus simple soit-il, est fiable s'il est "inconnu" ...
Je n'ai jamais dit cela. Tu peux essayer divers algorithmes de substitutions, diverses méthodes "classiques", etc. Tout dépend d'où provient ton fichier chiffré. Application ultra-sécurisée ? Jeu ? Défi ? Les niveaux de cryptographie diffèreront suivant les besoins et le niveau que requérait l'application qui l'a généré.
J'avoue que ça me laisse perplexe.
Si t'as aucune piste, c'est difficile de trouver. Si je te dis voici un cryptogramme, 1A75 F6AZ, qui contient un mot caché sans rien te dire d'autre, comment veux-tu le retrouver ? Tu vas essayer quelques algorithmes classiques, mais bon, cela relève du miracle et de la grosse chance. Tout dépend aussi de la longueur du cryptogramme. Celui-ci est trop court pour pouvoir tenter ne serait-ce qu'une analyse de fréquence.
Je pensais, sans doute à tort, que des outils et un peu de méthode et du temps, suffisaient à casser la plus part des algorithmes.
Non, ça, c'est à la télé... Si ton application utilise une méthode sûre, déjà, à la base, c'est incassable, même si tu connais l'algorithme. Alors, si en plus tu connais même pas l'algo et que le gars à fait du RSA ou d'autres trucs aussi comiques, tu peux aller te pendre... Bon, maintenant, c'est peut-être aussi simplement un XOR ou un rot13 hein...
-- AMcD®
http://arnold.mcdonald.free.fr/
Kevin Drapel
Je pensais, sans doute à tort, que des outils et un peu de méthode et du temps, suffisaient à casser la plus part des algorithmes. Non, ça, c'est à la télé...
Effectivement, il ne faut pas croire ce qu'on voit au cinéma. Par exemple, le très mauvais film "Opération Espadon" et son cassage de clés 128 bits à main en moins d'une minute. Car 2^128 = "3 suivi de 38 zéros" possibilités à tester. Impossible à l'heure actuelle même avec une armée d'ordinateurs.
Je pensais, sans doute à tort, que des outils et un peu de méthode et
du temps, suffisaient à casser la plus part des algorithmes.
Non, ça, c'est à la télé...
Effectivement, il ne faut pas croire ce qu'on voit au cinéma. Par
exemple, le très mauvais film "Opération Espadon" et son cassage de clés
128 bits à main en moins d'une minute. Car 2^128 = "3 suivi de 38 zéros"
possibilités à tester. Impossible à l'heure actuelle même avec une armée
d'ordinateurs.
Je pensais, sans doute à tort, que des outils et un peu de méthode et du temps, suffisaient à casser la plus part des algorithmes. Non, ça, c'est à la télé...
Effectivement, il ne faut pas croire ce qu'on voit au cinéma. Par exemple, le très mauvais film "Opération Espadon" et son cassage de clés 128 bits à main en moins d'une minute. Car 2^128 = "3 suivi de 38 zéros" possibilités à tester. Impossible à l'heure actuelle même avec une armée d'ordinateurs.
AMcD®
Kevin Drapel wrote:
Effectivement, il ne faut pas croire ce qu'on voit au cinéma. Par exemple, le très mauvais film "Opération Espadon" et son cassage de clés 128 bits à main en moins d'une minute. Car 2^128 = "3 suivi de 38 zéros" possibilités à tester. Impossible à l'heure actuelle même avec une armée d'ordinateurs.
Certes, mais tout est relatif.
Dans les calculs de faisabilité, je trouve qu'on abuse un peu des bits. Cela dépend quand même du type de clé utilisé.
Prenons l'exemple de clés sans aucune restriction de heu disons 80 bits. Bon 2^80 = 1.21E24, cela peut sembler énorme. Maintenant, suppose qu'il s'agit de clés pour des utilisateurs humains, genre ceux qu'ont déjà du mal à retenir leur numéro de téléphone. Là, ça va restreindre sévère. Tu va choisir les 26 lettres de l'alphabet et les 10 chiffres pour toute possibilité. 80 bits, c'est 10 caractères. Du coup, tu passes à 36^10 = 3.66E15, qui lui, se casse tranquilou en dégustant un Big Mac Coca. Pourtant, c'est toujours du 80 bits.
Le nombre de bits ne fait pas tout (nan, aucune allusion sexuelle) ;-).
-- AMcD®
http://arnold.mcdonald.free.fr/
Kevin Drapel wrote:
Effectivement, il ne faut pas croire ce qu'on voit au cinéma. Par
exemple, le très mauvais film "Opération Espadon" et son cassage de
clés 128 bits à main en moins d'une minute. Car 2^128 = "3 suivi de
38 zéros" possibilités à tester. Impossible à l'heure actuelle même
avec une armée d'ordinateurs.
Certes, mais tout est relatif.
Dans les calculs de faisabilité, je trouve qu'on abuse un peu des bits. Cela
dépend quand même du type de clé utilisé.
Prenons l'exemple de clés sans aucune restriction de heu disons 80 bits. Bon
2^80 = 1.21E24, cela peut sembler énorme. Maintenant, suppose qu'il s'agit
de clés pour des utilisateurs humains, genre ceux qu'ont déjà du mal à
retenir leur numéro de téléphone. Là, ça va restreindre sévère. Tu va
choisir les 26 lettres de l'alphabet et les 10 chiffres pour toute
possibilité. 80 bits, c'est 10 caractères. Du coup, tu passes à 36^10 =
3.66E15, qui lui, se casse tranquilou en dégustant un Big Mac Coca.
Pourtant, c'est toujours du 80 bits.
Le nombre de bits ne fait pas tout (nan, aucune allusion sexuelle) ;-).
Effectivement, il ne faut pas croire ce qu'on voit au cinéma. Par exemple, le très mauvais film "Opération Espadon" et son cassage de clés 128 bits à main en moins d'une minute. Car 2^128 = "3 suivi de 38 zéros" possibilités à tester. Impossible à l'heure actuelle même avec une armée d'ordinateurs.
Certes, mais tout est relatif.
Dans les calculs de faisabilité, je trouve qu'on abuse un peu des bits. Cela dépend quand même du type de clé utilisé.
Prenons l'exemple de clés sans aucune restriction de heu disons 80 bits. Bon 2^80 = 1.21E24, cela peut sembler énorme. Maintenant, suppose qu'il s'agit de clés pour des utilisateurs humains, genre ceux qu'ont déjà du mal à retenir leur numéro de téléphone. Là, ça va restreindre sévère. Tu va choisir les 26 lettres de l'alphabet et les 10 chiffres pour toute possibilité. 80 bits, c'est 10 caractères. Du coup, tu passes à 36^10 = 3.66E15, qui lui, se casse tranquilou en dégustant un Big Mac Coca. Pourtant, c'est toujours du 80 bits.
Le nombre de bits ne fait pas tout (nan, aucune allusion sexuelle) ;-).
-- AMcD®
http://arnold.mcdonald.free.fr/
Francois Grieu
Dans l'article <42b1606d$0$17062$, "AMcD®" wrote:
Prenons l'exemple de clés sans aucune restriction de heu disons 80 bits. Bon 2^80 = 1,21E24, cela peut sembler énorme. Maintenant, suppose qu'il s'agit de clés pour des utilisateurs humains, genre ceux qu'ont déjà du mal à retenir leur numéro de téléphone. Là, ça va restreindre sévère. Tu va choisir les 26 lettres de l'alphabet et les 10 chiffres pour toute possibilité. 80 bits, c'est 10 caractères. Du coup, tu passes à 36^10 = 3.66E15, qui lui, se casse tranquilou en dégustant un Big Mac Coca. Pourtant, c'est toujours du 80 bits.
Trois remarques:
- choisir une clé de 80 bits en la restreignant à être formée de 10 caractères choisi par l'utilisateur, ce n'est pas une bonne solution. Il est préférable de former les 8O bits par une fonction de hashage sur une chaîne de longueur libre d'être plus grande.
- il est aussi utile que la transformation chaîne->clé soit paramétrée par l'identification (publique) de l'utilisateur, car sinon il est souvent possible d'utiliser la multiplicité des utilisateurs pour diminuer considérablement le coût de la recherche exhaustive sur tous les utilisateurs, et/ou de la recherche pour un utilisateur non choisi.
- si le contexte le permet, il est de même utile de faire entrer une information publique mais variable (genre horodate) dans la transformation.
- il est utile que la transformation (horodate, utilisateur, chaîne) vers clé soit une peu couteuse; par exemple x := 0 repeter n fois clé := hash(x # horodate # utilisateur # chaîne) tronquer x pour produire la clé de la taille désirée.
Cela augmente le coût d'une recherche par dictionnaire, en proportion de n, dans la limite du coût d'une recherche exhaustive de la clé. En pratique on prend n le plus grand possible pour que le temps de calcul de la clé soit compatible avec l'ergonomie et le matériel utilisé.
Cette précaution, pourtant facile et extrèmement efficace, est trop rarement utilisée.
François Grieu
Dans l'article <42b1606d$0$17062$626a14ce@news.free.fr>,
"AMcD®" <arnold.mcdonald@free.fr> wrote:
Prenons l'exemple de clés sans aucune restriction de heu disons 80 bits.
Bon 2^80 = 1,21E24, cela peut sembler énorme. Maintenant, suppose qu'il
s'agit de clés pour des utilisateurs humains, genre ceux qu'ont déjà du
mal à retenir leur numéro de téléphone. Là, ça va restreindre sévère.
Tu va choisir les 26 lettres de l'alphabet et les 10 chiffres pour
toute possibilité. 80 bits, c'est 10 caractères. Du coup, tu passes
à 36^10 = 3.66E15, qui lui, se casse tranquilou en dégustant un Big
Mac Coca. Pourtant, c'est toujours du 80 bits.
Trois remarques:
- choisir une clé de 80 bits en la restreignant à être formée de 10
caractères choisi par l'utilisateur, ce n'est pas une bonne solution.
Il est préférable de former les 8O bits par une fonction de hashage
sur une chaîne de longueur libre d'être plus grande.
- il est aussi utile que la transformation chaîne->clé soit paramétrée
par l'identification (publique) de l'utilisateur, car sinon il est souvent
possible d'utiliser la multiplicité des utilisateurs pour diminuer
considérablement le coût de la recherche exhaustive sur tous les
utilisateurs, et/ou de la recherche pour un utilisateur non choisi.
- si le contexte le permet, il est de même utile de faire entrer
une information publique mais variable (genre horodate) dans la
transformation.
- il est utile que la transformation (horodate, utilisateur, chaîne)
vers clé soit une peu couteuse; par exemple
x := 0
repeter n fois
clé := hash(x # horodate # utilisateur # chaîne)
tronquer x pour produire la clé de la taille désirée.
Cela augmente le coût d'une recherche par dictionnaire,
en proportion de n, dans la limite du coût d'une recherche
exhaustive de la clé. En pratique on prend n le plus
grand possible pour que le temps de calcul de la clé soit
compatible avec l'ergonomie et le matériel utilisé.
Cette précaution, pourtant facile et extrèmement efficace, est trop
rarement utilisée.
Prenons l'exemple de clés sans aucune restriction de heu disons 80 bits. Bon 2^80 = 1,21E24, cela peut sembler énorme. Maintenant, suppose qu'il s'agit de clés pour des utilisateurs humains, genre ceux qu'ont déjà du mal à retenir leur numéro de téléphone. Là, ça va restreindre sévère. Tu va choisir les 26 lettres de l'alphabet et les 10 chiffres pour toute possibilité. 80 bits, c'est 10 caractères. Du coup, tu passes à 36^10 = 3.66E15, qui lui, se casse tranquilou en dégustant un Big Mac Coca. Pourtant, c'est toujours du 80 bits.
Trois remarques:
- choisir une clé de 80 bits en la restreignant à être formée de 10 caractères choisi par l'utilisateur, ce n'est pas une bonne solution. Il est préférable de former les 8O bits par une fonction de hashage sur une chaîne de longueur libre d'être plus grande.
- il est aussi utile que la transformation chaîne->clé soit paramétrée par l'identification (publique) de l'utilisateur, car sinon il est souvent possible d'utiliser la multiplicité des utilisateurs pour diminuer considérablement le coût de la recherche exhaustive sur tous les utilisateurs, et/ou de la recherche pour un utilisateur non choisi.
- si le contexte le permet, il est de même utile de faire entrer une information publique mais variable (genre horodate) dans la transformation.
- il est utile que la transformation (horodate, utilisateur, chaîne) vers clé soit une peu couteuse; par exemple x := 0 repeter n fois clé := hash(x # horodate # utilisateur # chaîne) tronquer x pour produire la clé de la taille désirée.
Cela augmente le coût d'une recherche par dictionnaire, en proportion de n, dans la limite du coût d'une recherche exhaustive de la clé. En pratique on prend n le plus grand possible pour que le temps de calcul de la clé soit compatible avec l'ergonomie et le matériel utilisé.
Cette précaution, pourtant facile et extrèmement efficace, est trop rarement utilisée.
François Grieu
Michel Arboi
On Thu Jun 16 2005 at 13:00, Kevin Drapel wrote:
le très mauvais film "Opération Espadon"
Au second degré, il était très drôle. Ce n'était peut-être pas l'intention du réalisateur :-]
On Thu Jun 16 2005 at 13:00, Kevin Drapel wrote:
le très mauvais film "Opération Espadon"
Au second degré, il était très drôle. Ce n'était peut-être pas
l'intention du réalisateur :-]
Dans les calculs de faisabilité, je trouve qu'on abuse un peu des bits. Cela dépend quand même du type de clé utilisé.
Les clés sont souvent générées de manière aléatoire, donc cette hypothèse tient.
AMcD®
Kevin Drapel wrote:
Les clés sont souvent générées de manière aléatoire, donc cette hypothèse tient.
T'as pas du trop désassembler d'application "usant" de cryptographie toi :-). Il est clair que de nos jours, plus de précautions sont mises en oeuvre dès lors qu'on utilise du chiffrement, mais bon, il fut un temps où cela n'était pas le cas. Il reste toujours des tas de softs, certains sont même actuellement écrits, d'autres le seront demain, où l'implémentation des méthodes de chiffrement est largement folklorique !
- Algos de génération de séquences aléatoires peu sérieux ; - Restrictions draconiennes d'ensembles de symboles pour la clé, diminuant de façon drastique le nombre de clés théoriques ; - Implémentation informatique olé olé à grand coup de failles potentielles ; - Algo de chiffrement peu sûr, quand ce n'est pas directement un truc "maison" ; - Etc.
Prends 10 codeurs au hasard qui ont à mettre un peu de crypto dans leur soft. 2 fois sur 3, les chefs de projets, cogniticiens, ingénieurs logiciels et autres architectes d'appli se cognent eperdument de la chose et le codeur va se débrouiller seul. Et 7 codeurs sur 10 auront leur propre idée de comment ils vont faire pour empêcher tous les hackers de casser leur truc. Parce que à eux, on la fait pas hein... Regarde comment l'ami Guillermito a massacré allégrement divers softs "pro" de stéganographie.
Les conseils de François Grieu sont loin d'être systématiquement employés, crois-moi...
-- AMcD®
http://arnold.mcdonald.free.fr/
Kevin Drapel wrote:
Les clés sont souvent générées de manière aléatoire, donc cette
hypothèse tient.
T'as pas du trop désassembler d'application "usant" de cryptographie toi
:-). Il est clair que de nos jours, plus de précautions sont mises en oeuvre
dès lors qu'on utilise du chiffrement, mais bon, il fut un temps où cela
n'était pas le cas. Il reste toujours des tas de softs, certains sont même
actuellement écrits, d'autres le seront demain, où l'implémentation des
méthodes de chiffrement est largement folklorique !
- Algos de génération de séquences aléatoires peu sérieux ;
- Restrictions draconiennes d'ensembles de symboles pour la clé, diminuant
de façon drastique le nombre de clés théoriques ;
- Implémentation informatique olé olé à grand coup de failles potentielles ;
- Algo de chiffrement peu sûr, quand ce n'est pas directement un truc
"maison" ;
- Etc.
Prends 10 codeurs au hasard qui ont à mettre un peu de crypto dans leur
soft. 2 fois sur 3, les chefs de projets, cogniticiens, ingénieurs logiciels
et autres architectes d'appli se cognent eperdument de la chose et le codeur
va se débrouiller seul. Et 7 codeurs sur 10 auront leur propre idée de
comment ils vont faire pour empêcher tous les hackers de casser leur truc.
Parce que à eux, on la fait pas hein... Regarde comment l'ami Guillermito a
massacré allégrement divers softs "pro" de stéganographie.
Les conseils de François Grieu sont loin d'être systématiquement employés,
crois-moi...
Les clés sont souvent générées de manière aléatoire, donc cette hypothèse tient.
T'as pas du trop désassembler d'application "usant" de cryptographie toi :-). Il est clair que de nos jours, plus de précautions sont mises en oeuvre dès lors qu'on utilise du chiffrement, mais bon, il fut un temps où cela n'était pas le cas. Il reste toujours des tas de softs, certains sont même actuellement écrits, d'autres le seront demain, où l'implémentation des méthodes de chiffrement est largement folklorique !
- Algos de génération de séquences aléatoires peu sérieux ; - Restrictions draconiennes d'ensembles de symboles pour la clé, diminuant de façon drastique le nombre de clés théoriques ; - Implémentation informatique olé olé à grand coup de failles potentielles ; - Algo de chiffrement peu sûr, quand ce n'est pas directement un truc "maison" ; - Etc.
Prends 10 codeurs au hasard qui ont à mettre un peu de crypto dans leur soft. 2 fois sur 3, les chefs de projets, cogniticiens, ingénieurs logiciels et autres architectes d'appli se cognent eperdument de la chose et le codeur va se débrouiller seul. Et 7 codeurs sur 10 auront leur propre idée de comment ils vont faire pour empêcher tous les hackers de casser leur truc. Parce que à eux, on la fait pas hein... Regarde comment l'ami Guillermito a massacré allégrement divers softs "pro" de stéganographie.
Les conseils de François Grieu sont loin d'être systématiquement employés, crois-moi...
-- AMcD®
http://arnold.mcdonald.free.fr/
Yannick Patois
Salut,
Gaël wrote:
A te lire on peut déduire que n'importe quel chiffrement, même le plus simple soit-il, est fiable s'il est "inconnu" ... J'avoue que ça me laisse perplexe. Je pensais, sans doute à tort, que des outils et un peu de méthode et du temps, suffisaient à casser la plus part des algorithmes.
Avec un seul fichier, pas facile.
Cependant, tu peux essayer de mesurer l'entropie de la séquence de bits du fichier ainsi que tenter une analyse en transformée de fourrier.
Si le système de cryptage est très mauvais, tu veras apparaitre quelque chose (des séquences plus probable et des périodicités) qui sera peut etre un début de piste, si l'algo de cryptage est décent ou que le fichier crypté ne possède pas trop de structure (compressé avant cryptage, par exemple), tu veras rien et tu ne seras pas beaucoup plus avancé...
A te lire on peut déduire que n'importe quel chiffrement, même le plus
simple soit-il, est fiable s'il est "inconnu" ...
J'avoue que ça me laisse perplexe.
Je pensais, sans doute à tort, que des outils et un peu de méthode et du
temps, suffisaient à casser la plus part des algorithmes.
Avec un seul fichier, pas facile.
Cependant, tu peux essayer de mesurer l'entropie de la séquence de bits
du fichier ainsi que tenter une analyse en transformée de fourrier.
Si le système de cryptage est très mauvais, tu veras apparaitre quelque
chose (des séquences plus probable et des périodicités) qui sera peut
etre un début de piste, si l'algo de cryptage est décent ou que le
fichier crypté ne possède pas trop de structure (compressé avant
cryptage, par exemple), tu veras rien et tu ne seras pas beaucoup plus
avancé...
A te lire on peut déduire que n'importe quel chiffrement, même le plus simple soit-il, est fiable s'il est "inconnu" ... J'avoue que ça me laisse perplexe. Je pensais, sans doute à tort, que des outils et un peu de méthode et du temps, suffisaient à casser la plus part des algorithmes.
Avec un seul fichier, pas facile.
Cependant, tu peux essayer de mesurer l'entropie de la séquence de bits du fichier ainsi que tenter une analyse en transformée de fourrier.
Si le système de cryptage est très mauvais, tu veras apparaitre quelque chose (des séquences plus probable et des périodicités) qui sera peut etre un début de piste, si l'algo de cryptage est décent ou que le fichier crypté ne possède pas trop de structure (compressé avant cryptage, par exemple), tu veras rien et tu ne seras pas beaucoup plus avancé...
