Perso, j'ai rien compris. Détaille un petit peu peut-être (quoi, un exemple ? ha oui, pas bête) ?
-- AMcD®
http://arnold.mcdonald.free.fr/
Yannick Patois
Salut,
AMcD® wrote:
Perso, j'ai rien compris. Détaille un petit peu peut-être (quoi, un exemple ? ha oui, pas bête) ?
L'énoncé me parait parfaitement clair (et interessant), mais j'ai peur de ne pas connaitre de solutions :(
Yannick
PS: Reformulation: Si tu as une séquence F (le fichier d'origine), tu peux calculer un checksum C et concaténer le deux pour faire la séquence FC.
La question est "est il possible de trouver C tel que C=C(FC) (et non C(F) )?" Autrement dit, que le checksum dans le fichier chechsum *aussi* le checksum ajouté à la fin du fichier.
Je crains que si l'algo de checksum est sur, ce ne soit pas possible.
Salut,
AMcD® wrote:
Perso, j'ai rien compris. Détaille un petit peu peut-être (quoi, un exemple
? ha oui, pas bête) ?
L'énoncé me parait parfaitement clair (et interessant), mais j'ai peur
de ne pas connaitre de solutions :(
Yannick
PS: Reformulation:
Si tu as une séquence F (le fichier d'origine), tu peux calculer un
checksum C et concaténer le deux pour faire la séquence FC.
La question est "est il possible de trouver C tel que C=C(FC) (et non
C(F) )?" Autrement dit, que le checksum dans le fichier chechsum *aussi*
le checksum ajouté à la fin du fichier.
Je crains que si l'algo de checksum est sur, ce ne soit pas possible.
Perso, j'ai rien compris. Détaille un petit peu peut-être (quoi, un exemple ? ha oui, pas bête) ?
L'énoncé me parait parfaitement clair (et interessant), mais j'ai peur de ne pas connaitre de solutions :(
Yannick
PS: Reformulation: Si tu as une séquence F (le fichier d'origine), tu peux calculer un checksum C et concaténer le deux pour faire la séquence FC.
La question est "est il possible de trouver C tel que C=C(FC) (et non C(F) )?" Autrement dit, que le checksum dans le fichier chechsum *aussi* le checksum ajouté à la fin du fichier.
Je crains que si l'algo de checksum est sur, ce ne soit pas possible.
Adrien Huvier
Yannick Patois wrote in news::
Si tu as une séquence F (le fichier d'origine), tu peux calculer un checksum C et concaténer le deux pour faire la séquence FC.
La question est "est il possible de trouver C tel que C=C(FC) (et non C(F) )?" Autrement dit, que le checksum dans le fichier chechsum *aussi* le checksum ajouté à la fin du fichier.
J'allais répondre, mais ta formulation est beaucoup plus claire :)
Je crains que si l'algo de checksum est sur, ce ne soit pas possible.
"checksum" me fait plutôt penser aux CRC habituellement sur 16 ou 32 bits, basés sur une division polynômiale. Ce qui n'a plus grand chose à voir avec la crypto, au passage, mais dans ce cas, il est peut-être possible de trouver une solution (si elle existe).
Au premier abord, je dirais qu'il n'y a pas de solution sauf si le CRC du message F est nul, mais j'avoue être honteusement rouillé en maths.
xpost et fu2 sur fr.sci.maths, pour voir ce qu'en pensent les autochtones...
-- Adrien Huvier
Yannick Patois <patois@calvix.org> wrote in
news:42C2DC07.4000406@calvix.org:
Si tu as une séquence F (le fichier d'origine), tu peux calculer un
checksum C et concaténer le deux pour faire la séquence FC.
La question est "est il possible de trouver C tel que C=C(FC) (et
non C(F) )?" Autrement dit, que le checksum dans le fichier
chechsum *aussi* le checksum ajouté à la fin du fichier.
J'allais répondre, mais ta formulation est beaucoup plus claire :)
Je crains que si l'algo de checksum est sur, ce ne soit pas
possible.
"checksum" me fait plutôt penser aux CRC habituellement sur 16 ou 32
bits, basés sur une division polynômiale. Ce qui n'a plus grand chose à
voir avec la crypto, au passage, mais dans ce cas, il est peut-être
possible de trouver une solution (si elle existe).
Au premier abord, je dirais qu'il n'y a pas de solution sauf si le CRC
du message F est nul, mais j'avoue être honteusement rouillé en maths.
xpost et fu2 sur fr.sci.maths, pour voir ce qu'en pensent les
autochtones...
Si tu as une séquence F (le fichier d'origine), tu peux calculer un checksum C et concaténer le deux pour faire la séquence FC.
La question est "est il possible de trouver C tel que C=C(FC) (et non C(F) )?" Autrement dit, que le checksum dans le fichier chechsum *aussi* le checksum ajouté à la fin du fichier.
J'allais répondre, mais ta formulation est beaucoup plus claire :)
Je crains que si l'algo de checksum est sur, ce ne soit pas possible.
"checksum" me fait plutôt penser aux CRC habituellement sur 16 ou 32 bits, basés sur une division polynômiale. Ce qui n'a plus grand chose à voir avec la crypto, au passage, mais dans ce cas, il est peut-être possible de trouver une solution (si elle existe).
Au premier abord, je dirais qu'il n'y a pas de solution sauf si le CRC du message F est nul, mais j'avoue être honteusement rouillé en maths.
xpost et fu2 sur fr.sci.maths, pour voir ce qu'en pensent les autochtones...
-- Adrien Huvier
Pierre Y.
Salut,
AMcD® wrote:
Perso, j'ai rien compris. Détaille un petit peu peut-être (quoi, un exemple ? ha oui, pas bête) ?
Yannick a compris.
L'énoncé me parait parfaitement clair (et interessant), mais j'ai peur de ne pas connaitre de solutions :(
J'ai tout simplement peur qu'il n'y en ait pas ;-) Et qu'au lieu d'être intéressante la question ne soit que stupide. Mais bon.
PS: Reformulation: Si tu as une séquence F (le fichier d'origine), tu peux calculer un checksum C et concaténer le deux pour faire la séquence FC.
La question est "est il possible de trouver C tel que C=C(FC) (et non C(F) )?" Autrement dit, que le checksum dans le fichier chechsum *aussi* le checksum ajouté à la fin du fichier.
Oui dans mon idée c'est même pire que ça, je voudrais inclure le checksum d'un fichier XML dans le fichier XML lui même donc en représentation ASCII (un exemple ? ah oui pas bête : 0xABC serait codé :
<donnees checksum="ABC"> ... </donnees>
)
De cette manière pour vérifier que le fichier n'a pas été modifié, je n'aurais qu'à calculer le checksum du fichier complet (avec le cheksum donc) et le vérifier ensuite. C'est le problème avec XML : les parsers tolèrent assez mal des données qui sont écrites avant ou après le noeud XML principal. Et même si j'inclus le checksum dans le noeud principal (dans un noeud exprès pour ou bien dans un noeud commentaire) il faudra que je commence par parser le fichier, que j'enlève le checksum et que parse le texte résultant sous réserve que mon parser XML renvoie le "texte XML" exactement comme l'a fait le parser qui m'aura permis de construire le fichier...
Bon c'est vrai aussi que je pourrais ne pas utiliser XML, mais c'est moins drôle ;-)
Je crains que si l'algo de checksum est sur, ce ne soit pas possible.
Oui, je pense comme toi, les seules techniques qui se rapprochent de ça (dans une certaine mesure, d'ailleurs l'idée vient de là) sont les CRC :
Soit
word CRC16(int E)
une fonction qui renvoie le CRC16 d'un entier (32 bits), si je passe à cette fonction un nombre sur 16 bits décalé de 16 bits à gauche, j'obtiens un CRC16 sur 16 bits :
word a = 0xABCD; word b = crc16(int(a) << 16);
et bien si je calcule :
word c = crc16((int(a) << 16) + int(b))
c = 0;
Mais ca tient au propriétés des CRC d'être le reste d'une division polynômiale. Avec un truc plus sérieux (MD5, SHA1, vous connaissez ça mieux que moi, pas besoin d'un dessin là ?) y'a aucune chance de s'approcher d'un début de semblant de résultat. Sinon (j'extrapole) c'est un peu comme si on arrivait à calculer des collisions pour ces algos non ?
Merci pour vos avis éclairés. A+
-- Pierre Y. KeyID : 0x7890CFE9
Salut,
AMcD® wrote:
Perso, j'ai rien compris. Détaille un petit peu peut-être (quoi, un exemple
? ha oui, pas bête) ?
Yannick a compris.
L'énoncé me parait parfaitement clair (et interessant), mais j'ai peur
de ne pas connaitre de solutions :(
J'ai tout simplement peur qu'il n'y en ait pas ;-) Et qu'au lieu d'être
intéressante la question ne soit que stupide. Mais bon.
PS: Reformulation:
Si tu as une séquence F (le fichier d'origine), tu peux calculer un
checksum C et concaténer le deux pour faire la séquence FC.
La question est "est il possible de trouver C tel que C=C(FC) (et non
C(F) )?" Autrement dit, que le checksum dans le fichier chechsum *aussi*
le checksum ajouté à la fin du fichier.
Oui dans mon idée c'est même pire que ça, je voudrais inclure le
checksum d'un fichier XML dans le fichier XML lui même donc en
représentation ASCII (un exemple ? ah oui pas bête : 0xABC serait codé :
<donnees checksum="ABC">
...
</donnees>
)
De cette manière pour vérifier que le fichier n'a pas été modifié, je
n'aurais qu'à calculer le checksum du fichier complet (avec le cheksum
donc) et le vérifier ensuite. C'est le problème avec XML : les parsers
tolèrent assez mal des données qui sont écrites avant ou après le noeud
XML principal. Et même si j'inclus le checksum dans le noeud principal
(dans un noeud exprès pour ou bien dans un noeud commentaire) il faudra
que je commence par parser le fichier, que j'enlève le checksum et que
parse le texte résultant sous réserve que mon parser XML renvoie le
"texte XML" exactement comme l'a fait le parser qui m'aura permis de
construire le fichier...
Bon c'est vrai aussi que je pourrais ne pas utiliser XML, mais c'est
moins drôle ;-)
Je crains que si l'algo de checksum est sur, ce ne soit pas possible.
Oui, je pense comme toi, les seules techniques qui se rapprochent de ça
(dans une certaine mesure, d'ailleurs l'idée vient de là) sont les CRC :
Soit
word CRC16(int E)
une fonction qui renvoie le CRC16 d'un entier (32 bits), si je passe à
cette fonction un nombre sur 16 bits décalé de 16 bits à gauche,
j'obtiens un CRC16 sur 16 bits :
word a = 0xABCD;
word b = crc16(int(a) << 16);
et bien si je calcule :
word c = crc16((int(a) << 16) + int(b))
c = 0;
Mais ca tient au propriétés des CRC d'être le reste d'une division
polynômiale. Avec un truc plus sérieux (MD5, SHA1, vous connaissez ça
mieux que moi, pas besoin d'un dessin là ?) y'a aucune chance de
s'approcher d'un début de semblant de résultat. Sinon (j'extrapole)
c'est un peu comme si on arrivait à calculer des collisions pour ces
algos non ?
Perso, j'ai rien compris. Détaille un petit peu peut-être (quoi, un exemple ? ha oui, pas bête) ?
Yannick a compris.
L'énoncé me parait parfaitement clair (et interessant), mais j'ai peur de ne pas connaitre de solutions :(
J'ai tout simplement peur qu'il n'y en ait pas ;-) Et qu'au lieu d'être intéressante la question ne soit que stupide. Mais bon.
PS: Reformulation: Si tu as une séquence F (le fichier d'origine), tu peux calculer un checksum C et concaténer le deux pour faire la séquence FC.
La question est "est il possible de trouver C tel que C=C(FC) (et non C(F) )?" Autrement dit, que le checksum dans le fichier chechsum *aussi* le checksum ajouté à la fin du fichier.
Oui dans mon idée c'est même pire que ça, je voudrais inclure le checksum d'un fichier XML dans le fichier XML lui même donc en représentation ASCII (un exemple ? ah oui pas bête : 0xABC serait codé :
<donnees checksum="ABC"> ... </donnees>
)
De cette manière pour vérifier que le fichier n'a pas été modifié, je n'aurais qu'à calculer le checksum du fichier complet (avec le cheksum donc) et le vérifier ensuite. C'est le problème avec XML : les parsers tolèrent assez mal des données qui sont écrites avant ou après le noeud XML principal. Et même si j'inclus le checksum dans le noeud principal (dans un noeud exprès pour ou bien dans un noeud commentaire) il faudra que je commence par parser le fichier, que j'enlève le checksum et que parse le texte résultant sous réserve que mon parser XML renvoie le "texte XML" exactement comme l'a fait le parser qui m'aura permis de construire le fichier...
Bon c'est vrai aussi que je pourrais ne pas utiliser XML, mais c'est moins drôle ;-)
Je crains que si l'algo de checksum est sur, ce ne soit pas possible.
Oui, je pense comme toi, les seules techniques qui se rapprochent de ça (dans une certaine mesure, d'ailleurs l'idée vient de là) sont les CRC :
Soit
word CRC16(int E)
une fonction qui renvoie le CRC16 d'un entier (32 bits), si je passe à cette fonction un nombre sur 16 bits décalé de 16 bits à gauche, j'obtiens un CRC16 sur 16 bits :
word a = 0xABCD; word b = crc16(int(a) << 16);
et bien si je calcule :
word c = crc16((int(a) << 16) + int(b))
c = 0;
Mais ca tient au propriétés des CRC d'être le reste d'une division polynômiale. Avec un truc plus sérieux (MD5, SHA1, vous connaissez ça mieux que moi, pas besoin d'un dessin là ?) y'a aucune chance de s'approcher d'un début de semblant de résultat. Sinon (j'extrapole) c'est un peu comme si on arrivait à calculer des collisions pour ces algos non ?
Merci pour vos avis éclairés. A+
-- Pierre Y. KeyID : 0x7890CFE9
Roland Le Franc
Passons sur la difficulté anecdotique d'inclure le checksum en ASCII et avant le noeud (c'est quoi) du XML, le principe me parait discutable.
Même s'il y a une méthode déterministe pour transformer le texte initial F en un texte F' qui contient son propre checksum (peut être facile, difficile ou impossible, selon le checksum choisi), alors ce n'est pas une preuve que le fichier F' est bien un fichier original non modifié. Qu'est ce qui empeche quiconque de modifier F en G, puis générer de la même manière G' et arguer de la même preuve d'authenticité?
Il reste que la source du texte doit donner aussi le checksum sur son site, ce qui nous ramène à la technique habituelle ou les fichiers disponibles sur le web sont accompagnés d'un petit texte qui donne leur hash (exemple des distributions linux)
Si le problème était plutot de prouver que vous (une personne précise) etes l'auteur du fichier original, les techniques habituelles de signatures sont faites pour ca.
Oui dans mon idée c'est même pire que ça, je voudrais inclure le checksum d'un fichier XML dans le fichier XML lui même donc en représentation ASCII (un exemple ? ah oui pas bête : 0xABC serait codé :
<donnees checksum="ABC"> .... </donnees>
)
De cette manière pour vérifier que le fichier n'a pas été modifié, je n'aurais qu'à calculer le checksum du fichier complet (avec le cheksum donc) et le vérifier ensuite. C'est le problème avec XML : les parsers tolèrent assez mal des données qui sont écrites avant ou après le noeud XML principal. Et même si j'inclus le checksum dans le noeud principal (dans un noeud exprès pour ou bien dans un noeud commentaire) il faudra que je commence par parser le fichier, que j'enlève le checksum et que parse le texte résultant sous réserve que mon parser XML renvoie le "texte XML" exactement comme l'a fait le parser qui m'aura permis de construire le fichier...
Bon c'est vrai aussi que je pourrais ne pas utiliser XML, mais c'est moins drôle ;-)
Passons sur la difficulté anecdotique d'inclure le checksum en ASCII et
avant le noeud (c'est quoi) du XML, le principe me parait discutable.
Même s'il y a une méthode déterministe pour transformer le texte initial
F en un texte F' qui contient son propre checksum (peut être facile,
difficile ou impossible, selon le checksum choisi), alors ce n'est pas
une preuve que le fichier F' est bien un fichier original non modifié.
Qu'est ce qui empeche quiconque de modifier F en G, puis générer de la
même manière G' et arguer de la même preuve d'authenticité?
Il reste que la source du texte doit donner aussi le checksum sur son
site, ce qui nous ramène à la technique habituelle ou les fichiers
disponibles sur le web sont accompagnés d'un petit texte qui donne leur
hash (exemple des distributions linux)
Si le problème était plutot de prouver que vous (une personne précise)
etes l'auteur du fichier original, les techniques habituelles de
signatures sont faites pour ca.
Oui dans mon idée c'est même pire que ça, je voudrais inclure le
checksum d'un fichier XML dans le fichier XML lui même donc en
représentation ASCII (un exemple ? ah oui pas bête : 0xABC serait codé :
<donnees checksum="ABC">
....
</donnees>
)
De cette manière pour vérifier que le fichier n'a pas été modifié, je
n'aurais qu'à calculer le checksum du fichier complet (avec le cheksum
donc) et le vérifier ensuite. C'est le problème avec XML : les parsers
tolèrent assez mal des données qui sont écrites avant ou après le noeud
XML principal. Et même si j'inclus le checksum dans le noeud principal
(dans un noeud exprès pour ou bien dans un noeud commentaire) il faudra
que je commence par parser le fichier, que j'enlève le checksum et que
parse le texte résultant sous réserve que mon parser XML renvoie le
"texte XML" exactement comme l'a fait le parser qui m'aura permis de
construire le fichier...
Bon c'est vrai aussi que je pourrais ne pas utiliser XML, mais c'est
moins drôle ;-)
Passons sur la difficulté anecdotique d'inclure le checksum en ASCII et avant le noeud (c'est quoi) du XML, le principe me parait discutable.
Même s'il y a une méthode déterministe pour transformer le texte initial F en un texte F' qui contient son propre checksum (peut être facile, difficile ou impossible, selon le checksum choisi), alors ce n'est pas une preuve que le fichier F' est bien un fichier original non modifié. Qu'est ce qui empeche quiconque de modifier F en G, puis générer de la même manière G' et arguer de la même preuve d'authenticité?
Il reste que la source du texte doit donner aussi le checksum sur son site, ce qui nous ramène à la technique habituelle ou les fichiers disponibles sur le web sont accompagnés d'un petit texte qui donne leur hash (exemple des distributions linux)
Si le problème était plutot de prouver que vous (une personne précise) etes l'auteur du fichier original, les techniques habituelles de signatures sont faites pour ca.
Oui dans mon idée c'est même pire que ça, je voudrais inclure le checksum d'un fichier XML dans le fichier XML lui même donc en représentation ASCII (un exemple ? ah oui pas bête : 0xABC serait codé :
<donnees checksum="ABC"> .... </donnees>
)
De cette manière pour vérifier que le fichier n'a pas été modifié, je n'aurais qu'à calculer le checksum du fichier complet (avec le cheksum donc) et le vérifier ensuite. C'est le problème avec XML : les parsers tolèrent assez mal des données qui sont écrites avant ou après le noeud XML principal. Et même si j'inclus le checksum dans le noeud principal (dans un noeud exprès pour ou bien dans un noeud commentaire) il faudra que je commence par parser le fichier, que j'enlève le checksum et que parse le texte résultant sous réserve que mon parser XML renvoie le "texte XML" exactement comme l'a fait le parser qui m'aura permis de construire le fichier...
Bon c'est vrai aussi que je pourrais ne pas utiliser XML, mais c'est moins drôle ;-)
Jérémy JUST
On 29 Jun 2005 09:52:31 -0700 "Pierre Y." wrote:
Est-ce qu'il existe une algo, une méthode, une astuce qui permet de calculer le checksum d'un fichier qui contiendra ce checksum ?
Le terme de « checksum » laisse beaucoup de place à l'imagination.
Si tu prends comme checksum le nombre de caractères du fichier, tu pourras sans problème prédire la somme de contrôle du fichier qui recevra cette somme.
Par exemple, pour le corps de ce post: 528
-- Jérémy JUST
On 29 Jun 2005 09:52:31 -0700
"Pierre Y." <pierre.y@gmail.com> wrote:
Est-ce qu'il existe une algo, une méthode, une astuce qui permet de
calculer le checksum d'un fichier qui contiendra ce checksum ?
Le terme de « checksum » laisse beaucoup de place à l'imagination.
Si tu prends comme checksum le nombre de caractères du fichier, tu
pourras sans problème prédire la somme de contrôle du fichier qui
recevra cette somme.
Est-ce qu'il existe une algo, une méthode, une astuce qui permet de calculer le checksum d'un fichier qui contiendra ce checksum ?
Le terme de « checksum » laisse beaucoup de place à l'imagination.
Si tu prends comme checksum le nombre de caractères du fichier, tu pourras sans problème prédire la somme de contrôle du fichier qui recevra cette somme.
Par exemple, pour le corps de ce post: 528
-- Jérémy JUST
Christophe HENRY
Est-ce qu'il existe une algo, une méthode, une astuce qui permet de calculer le checksum d'un fichier qui contiendra ce checksum ? C'est un peu le problème de l'oeuf ou de la poule qui fait l'oeuf, je ne sais pas s'il y a une solution.
Ton problème est qu'il est impossible de faire simplement cette somme puis de l'inscrire dans le fichier puisque cela modifie aussi la somme de contrôle résultante. Problème facile si cette somme est le nombre de caractère du texte, délicat s'il s'agit de xor sur le texte, calculatoirement infaisable (amha) si c'est du MD5. Ou alors on a pu trouver une manière de faire des collisions.
En fait, on peut aussi très bien calculer la somme de contrôle sur tout le fichier, sauf sur la somme de contrôle elle-même. L'intégrité du fichier est-elle préservée ? Oui : si le fichier hors somme est modifié, la somme résultante sera différente de la somme stockée. Si la somme elle-même est modifiée, elle sera différente de la somme résultante du fichier. Evidemment, il sera toujours (très peu, selon algo) possible d'avoir une modification du fichier hors somme avec une même somme résultante, une collision donc.
Ceci dit, tout n'est pas fait. Comme l'avance Roland, cela ne protège que contre les modifications involontaires. Les protocoles réseaux implémentent ces sommes de contrôle depuis le début. Il faut aussi protéger contre une modification pirate du contenu ; l'attaquant ne doit pas pouvoir regénérer la somme de contrôle lui-même et la faire paraître authentique. Il faut donc signer numériquement.
Au final, avec une somme de contrôle signée numériquement portant sur le fichier, sans la somme de contrôle signée, ton but pourrait être atteint.
Au plaisir,
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Est-ce qu'il existe une algo, une méthode, une astuce qui permet de
calculer le checksum d'un fichier qui contiendra ce checksum ?
C'est un peu le problème de l'oeuf ou de la poule qui fait l'oeuf, je
ne sais pas s'il y a une solution.
Ton problème est qu'il est impossible de faire simplement cette somme
puis de l'inscrire dans le fichier puisque cela modifie aussi la somme de
contrôle résultante. Problème facile si cette somme est le nombre de
caractère du texte, délicat s'il s'agit de xor sur le texte,
calculatoirement infaisable (amha) si c'est du MD5. Ou alors on a pu
trouver une manière de faire des collisions.
En fait, on peut aussi très bien calculer la somme de contrôle sur tout
le fichier, sauf sur la somme de contrôle elle-même. L'intégrité du
fichier est-elle préservée ? Oui : si le fichier hors somme est
modifié, la somme résultante sera différente de la somme stockée. Si
la somme elle-même est modifiée, elle sera différente de la somme
résultante du fichier. Evidemment, il sera toujours (très peu, selon
algo) possible d'avoir une modification du fichier hors somme avec une
même somme résultante, une collision donc.
Ceci dit, tout n'est pas fait. Comme l'avance Roland, cela ne protège que
contre les modifications involontaires. Les protocoles réseaux
implémentent ces sommes de contrôle depuis le début. Il faut aussi
protéger contre une modification pirate du contenu ; l'attaquant ne doit
pas pouvoir regénérer la somme de contrôle lui-même et la faire
paraître authentique. Il faut donc signer numériquement.
Au final, avec une somme de contrôle signée numériquement portant sur
le fichier, sans la somme de contrôle signée, ton but pourrait être
atteint.
Au plaisir,
--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Est-ce qu'il existe une algo, une méthode, une astuce qui permet de calculer le checksum d'un fichier qui contiendra ce checksum ? C'est un peu le problème de l'oeuf ou de la poule qui fait l'oeuf, je ne sais pas s'il y a une solution.
Ton problème est qu'il est impossible de faire simplement cette somme puis de l'inscrire dans le fichier puisque cela modifie aussi la somme de contrôle résultante. Problème facile si cette somme est le nombre de caractère du texte, délicat s'il s'agit de xor sur le texte, calculatoirement infaisable (amha) si c'est du MD5. Ou alors on a pu trouver une manière de faire des collisions.
En fait, on peut aussi très bien calculer la somme de contrôle sur tout le fichier, sauf sur la somme de contrôle elle-même. L'intégrité du fichier est-elle préservée ? Oui : si le fichier hors somme est modifié, la somme résultante sera différente de la somme stockée. Si la somme elle-même est modifiée, elle sera différente de la somme résultante du fichier. Evidemment, il sera toujours (très peu, selon algo) possible d'avoir une modification du fichier hors somme avec une même somme résultante, une collision donc.
Ceci dit, tout n'est pas fait. Comme l'avance Roland, cela ne protège que contre les modifications involontaires. Les protocoles réseaux implémentent ces sommes de contrôle depuis le début. Il faut aussi protéger contre une modification pirate du contenu ; l'attaquant ne doit pas pouvoir regénérer la somme de contrôle lui-même et la faire paraître authentique. Il faut donc signer numériquement.
Au final, avec une somme de contrôle signée numériquement portant sur le fichier, sans la somme de contrôle signée, ton but pourrait être atteint.
Au plaisir,
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Kevin Drapel
Ton problème est qu'il est impossible de faire simplement cette somme puis de l'inscrire dans le fichier puisque cela modifie aussi la somme de contrôle résultante. Problème facile si cette somme est le nombre de caractère du texte, délicat s'il s'agit de xor sur le texte, calculatoirement infaisable (amha) si c'est du MD5. Ou alors on a pu trouver une manière de faire des collisions.
Pour "inverser" un CRC (c'est à dire conserver le même CRC et changer les données) :
http://www.woodmann.com/fravia/crctut1.htm
Et effectivement, si c'est une fonction de hachage cryptographique, cela revient à trouver une attaque sur les préimages (avec une contrainte forte vu que le message ainsi forgé ne doit pas être aléatoire). Possible avec MD4 (Dobbertin a fait une manip similaire sur un texte avec un bout d'aléatoire au début) mais pas avec SHA-1 ou pire, Whirlpool.
Ton problème est qu'il est impossible de faire simplement cette somme
puis de l'inscrire dans le fichier puisque cela modifie aussi la somme de
contrôle résultante. Problème facile si cette somme est le nombre de
caractère du texte, délicat s'il s'agit de xor sur le texte,
calculatoirement infaisable (amha) si c'est du MD5. Ou alors on a pu
trouver une manière de faire des collisions.
Pour "inverser" un CRC (c'est à dire conserver le même CRC et changer
les données) :
http://www.woodmann.com/fravia/crctut1.htm
Et effectivement, si c'est une fonction de hachage cryptographique, cela
revient à trouver une attaque sur les préimages (avec une contrainte
forte vu que le message ainsi forgé ne doit pas être aléatoire).
Possible avec MD4 (Dobbertin a fait une manip similaire sur un texte
avec un bout d'aléatoire au début) mais pas avec SHA-1 ou pire, Whirlpool.
Ton problème est qu'il est impossible de faire simplement cette somme puis de l'inscrire dans le fichier puisque cela modifie aussi la somme de contrôle résultante. Problème facile si cette somme est le nombre de caractère du texte, délicat s'il s'agit de xor sur le texte, calculatoirement infaisable (amha) si c'est du MD5. Ou alors on a pu trouver une manière de faire des collisions.
Pour "inverser" un CRC (c'est à dire conserver le même CRC et changer les données) :
http://www.woodmann.com/fravia/crctut1.htm
Et effectivement, si c'est une fonction de hachage cryptographique, cela revient à trouver une attaque sur les préimages (avec une contrainte forte vu que le message ainsi forgé ne doit pas être aléatoire). Possible avec MD4 (Dobbertin a fait une manip similaire sur un texte avec un bout d'aléatoire au début) mais pas avec SHA-1 ou pire, Whirlpool.
