Bonsoir cher journal,
Je réfléchissais ce soir à la somme MD5. Puis-je l'utiliser pour certifier à une tierce personne que je ne modifie pas un document ?
Je m'explique : imaginons que je détienne un document confidentiel que je n'aie pas le droit de modifier. Imaginons encore qu'il me faut prouver à une autorité extérieure que je ne modifie pas le document sans lui en divulguer le contenu dans un premier temps (car le contenu est temporairement confidentiel). Ainsi, je déclare à l'autorité que le document est figé au temps t ; l'autorité ne peut accéder au document qu'au temps t+1. A t+1, j'envoie donc le document à l'autorité et je veux qu'elle puisse vérifier qu'aucune modification n'a été faite entre t et t+1.
Est-il valable de :
- générer l'empreinte MD5 de mon document à t (on la notera MD5(doc,t))
- à t, envoyer l'empreinte MD5(doc,t) à l'autorité
Plus tard
- à t+1, envoyer le document à l'autorité
- l'autorité peut calculer MD5(doc, t+1)
Si MD5(doc,t+1)=MD5(doc,t), l'autorité peut-elle conclure que le fichier n'a pas été modifié ?
Inversement, si MD5(doc,t+1)=MD5(doc,t), l'autorité peut-elle conclure que le fichier a été modifié ?
Qu'en pensez-vous ? Bonne soirée à tous.
# Euh... Oui
Posté par krion . Évalué à 1.
Je pense que tu voulais dire != sur la deuxième ligne ?
Sinon, le temps n'impacte en rien la somme md5, donc je comprends pas trop le fond de ta pensée.
Pourquoi ne pas envoyer le MD5 en même temps que le document ?
[^] # Re: Euh... Oui
Posté par Pierre Alain B. . Évalué à 1.
Oui pardon, la question est bien :
Inversement, si MD5(doc,t+1)!=MD5(doc,t), l'autorité peut-elle conclure que le fichier a été modifié ?
Le temps n'impacte pas, je suis bien d'accord. Mais je suis peut-être très malhonnête et j'ai peut-être intérêt à vouloir modifier le document... Le but de l'autorité est bien sûr de m'empêcher de modifier le document. Mais, pour des raisons de confidentialité, je ne peux pas lui envoyer le document à t.
En fait, j'essaye de me passer d'un tiers de confiance qui pourrait garantir à l'autorité que je ne modifies pas le document. La somme MD5 (qui ne dévoile pas le contenu) peut-elle remplacer le tiers de confiance en m'empêcher de tricher en modifiant le document entre t et t+1 et en le cachant à l'autorité ?
(je ne sais pas si tout cela rend la chose plus claire)
[^] # Re: Euh... Oui
Posté par BB . Évalué à 2.
C’est là où je tique. Comment garantis-tu que tu n’a pas déjà modifié le document à t ? Comment garantis-tu que la forme hashé/chiffrée/etc. envoyée à t n’est pas déjà la version frauduleusement modifiée du document ?
[^] # Re: Euh... Oui
Posté par beagf (site web personnel) . Évalué à 10.
L'objectif est de prouver que tu n'as pas modifier un document entre «t» et «t+1», c'est tout. C'est un peu un principe d'enveloppe scellée, tu peux prouver que tu possedais un document à un instant dans le passé.
On peu faire un système de vente en aveugle comme ça :
- chaque personne intéressée écris un document avec son offre et publie le md5 ;
- quand tout le monde à publié son md5 on publie les documents.
Comme ça personne ne peut modifier son offre après l'avoir déposée, et personne ne connait l'offre des autres avant de poster la sienne. Et tout ça sans tier de confiance.
# trop tard !
Posté par nomorsad . Évalué à 7.
Ton IPoT est mal reglé, ça existe déjà depuis 20 ans et ça s'appelle la Signature_numérique
[^] # Re: trop tard !
Posté par Pierre Alain B. . Évalué à 1.
Mon IPoT ?
Mais la signature numérique rajoute justement une notion d'authentification (identité de l'auteur) non ? Or si je cherche juste la non altération, je n'ai pas besoin de cette couche.
Auquel cas, SHA-256 suffit-il pour certifier la non altération ?
Finalement, cela revient alors à ne garder que l'étape SHA du fonctionnement décrit dans la page que tu cites ?
[^] # Re: trop tard !
Posté par imr . Évalué à 2.
Tu ne peux pas connaitre, ça n'a pas encore été inventé, mais c'est déjà beaucoup utilisé.
[^] # Re: trop tard !
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
Il faut une entrée dans le wiki pour l'iPoT.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: trop tard !
Posté par MarbolanGos (site web personnel) . Évalué à 1.
Et faire attention parce que chez une marque de fruit ils risquent de dire qu'ils ont la paternité
[^] # Re: trop tard !
Posté par zebra3 . Évalué à 3.
Andros et sa comPoT ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: trop tard !
Posté par kowalsky . Évalué à 3.
J'ai déjà fait une entré dans le wiki pour iPoT, mais je l'ai faite dans deux ans.
[^] # Re: trop tard !
Posté par nomorsad . Évalué à 1.
Vieille blague, désolé...
Ça peut, mais pas seulement! La signature numérique assure également l'intégrité du document.
Il suffit que celui qui signe soit une "autorité d'horodatage" et que la date soit inclue dans la signature.
Voir Horodatage, ou plus complet, en Anglais : en:Trusted_timestamping
Pour ce qui est de l'algorithme utilisé, je n'entrerai pas dans le débat du "MD5 c'est troué, le SHA saimieu!", car les algorithmes sont comme l'informatique : les algos qui sont sécure à l'instant T ne le sont pas forcement à T+1...
# Oui ça fonctionne
Posté par Jux (site web personnel) . Évalué à 4.
Je ne suis pas sûr de ce que tu entends par MD5(doc, t):
1) "On prend le hash de doc au temps t"
2) "On prend le hash de doc concaténé à t"
Si tu sous-entends 1), alors ça fonctionne pour autant que ta fonction de hachage résiste aux collisions et/ou aux attaques par pré-image. Si elle n'est pas résistante à une des ces catégories d'attaques, il est possible d'avoir hash(doc1) = hash(doc2) avec doc1 != doc2.
En l'occurence MD5 n'est pas résistant aux collisions, donc tourne-toi plutôt du côté de SHA-256 (qui a aussi quelques attaques connues, mais nettement plus théoriques il me semble).
[^] # Re: Oui ça fonctionne
Posté par Pierre Alain B. . Évalué à 2.
J'entendais bien 1).
Merci beaucoup pour ta réponse.
[^] # Re: Oui ça fonctionne
Posté par Pierre Tramal (site web personnel) . Évalué à 5.
Ca il est toujours possible de l'avoir, quelle que soit la fonction de hash (puisqu'elle n'est nécessairement pas bijective). La question est surtout de savoir s'il est simple de trouver un doc2 à partir de doc1 (et également si doc2 a un "sens" dans le contexte qui nous intéresse; exemple bidon: si doc1 est une phrase en francais est ce qu'on peut trouver une autre phrase ayant un sens et ayant le même hash).
[^] # Re: Oui ça fonctionne
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 1.
Il me semble que pour md5 c'est faisable de créer un autre doc "qui a un sens"
par contre si on donne un sha et un md5, quelle est la probabilité de créer un doc ayant les 2 signatures identiques ?
# Techniquement oui.
Posté par Jehan (site web personnel, Mastodon) . Évalué à 5.
Salut,
tout dépend de la personne. Si la personne est un minimum compétente en informatique, oui. "Compétente" non dans le sens où elle doit réellement appréhender les détails algorithmiques, mais au moins globalement comprendre le principe d'une fonction de hachage. Parce qu'un "quidam" moyen, s'il ne veut pas comprendre, tu pourras lui expliquer comme tu veux, ça reste de l'algorithmique, donc c'est compliqué et il te dira qu'y a sûrement des moyens de trafiquer (même s'il saura pas te dire comment) parce que l'informatique, c'est magique.
Plus simple évidemment serait s'il y avait une quelconque reconnaissance légale de ce genre de procédé.
Bon en aparté, à ta place, je prendrais une fonction un chouille plus robuste comme SHA-1 (qui est dispo partout maintenant, comme MD5) car MD5, c'est de plus en plus abandonné puisque depuis quelques années, "on" sait créer des collisions pour une signature donnée (générer un autre "document" qui génère la même signature). Bon dans ton cas précis, je ne pense pas que ça ait la moindre importance (ce sont des documents avec du langage humain a priori dont tu parles, donc avant d'arriver automatiquement à créer un second document qui utilise le même langage, avec un sens compréhensible et qui aurait la même signature, faudra se lever tôt), mais au moins t'es sûr de pas avoir de plainte avec SHA-1, même avec quelqu'un de mauvaise foi. :-)
Sinon globalement tu peux utiliser la partie "signature" des algorithmes asymétriques (PGP et compagnie). Bon ça fait globalement la même chose exactement que ce que fera ta proposition avec MD5 (ou SHA-1), puisque tu t'intéresses uniquement à garantir l'intégrité de ton document (il est pas modifié).
Mais je parle de ça uniquement parce qu'a priori, d'après Wikipedia (http://fr.wikipedia.org/wiki/Signature_num%C3%A9rique#Valeur_l.C3.A9gale), ça aurait une valeur légale. Ensuite si tu fais ça dans ton coin (sans passer par un notaire ou autre), je sais pas si ça en a plus que du SHA-1, mais bon, c'est une idée en l'air.
Donc réponse courte: techniquement, oui.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Techniquement oui.
Posté par Pseudo007 . Évalué à -1.
C'est vraiment un des boulots de PGP, donc autant l'utiliser.
PGP : Le document est signé par celui qui l'émet et tout le monde peut contrôler cette signature (du moment qu'on a la clé public, et la clé public est faite pour être diffusée).
Enfin MD5 a montré ses limites, dans des conditions particulières (dont j'ignore tout) on peut modifier un document et que la signature ne change pas (avec un toujours un document "lisible", évidemment).
SHA1 pallie à cette faiblesse de MD5.
PGP est la solution, MD5 ou SHA1 peut-être utilisé si on ne veut pas s'embarrasser d'avoir une clé secret PGP.
[^] # Re: Techniquement oui.
Posté par Aldoo . Évalué à 2.
Attention, comparer PGP et MD5 ou SHA1, c'est comme comparer le fait d'écrire un mail avec le fait d'écrire en Français ou en Anglais. Ça ne se situe pas au même niveau.
PGP n'est pas un algorithme de crypto ou de hashage, mais juste un protocole qui utilise de tels algorithmes. PGP utilisait traditionnellement MD5. Je suppose que maintenant que MD5 est réputé faillible, SHA1 et d'autres lui sont préférés.
# MD5 n'est pas infaillible
Posté par Serge Julien . Évalué à 5.
En fait, ce que tu décrit est correct dans les grandes lignes, mais...
le hash MD5 contient un nombre fini de bits, alors que l'ensemble des données d'entrée est potentiellement infini. Pour une empreinte MD5 donnée, tu as donc théoriquement un nombre infini de fichiers qui correspondent. Mais bon, la plupart sont des suites de bytes qui n'ont aucun sens...
cependant, MD5 possède des failles qui ont été révélées il y a quelques années. En gros, sous certaines conditions, tu peux altérer un document de telle façon que la version modifiée possède la même empreinte MD5 que l'original (voir par exemple ici).
Pour le besoin que tu décris, je pense que le scénario le plus simple est le suivant: tu chiffres ton document avec un algorithme à clé secrète (AES, par exemple) en utilisant une clé générée aléatoirement (et qui ne resservira jamais). Tu envoies ton document ainsi chiffré. Plus tard, pour la vérification, tu envoies le document en clair et la clé de chiffrement. L'autorité déchiffre le document précédemment envoyé et le compare au clair, et le tour est joué...
[^] # Re: MD5 n'est pas infaillible
Posté par Pierre Alain B. . Évalué à 1.
Merci, c'est effectivement une autre possibilité intéressante - dumoins si je fais confiance à mon algorithme de cryptage (si j'ai vraiment peur de ce que pourrait tenter l'autorité !).
Merci encore
[^] # Re: MD5 n'est pas infaillible
Posté par Julien Humbert . Évalué à 10.
Je pense que tu peux faire confiance aux algorithmes. Ça me rappelle surtout ce strip de XKCD.
[^] # Re: MD5 n'est pas infaillible
Posté par mickabouille . Évalué à 9.
Moi ça me rappelle surtout le 2e tableau de
http://valerieaurora.org/hash.html
[^] # Re: MD5 n'est pas infaillible
Posté par claudex . Évalué à 3.
Il y a même déjà eu des exemples de collision http://www.win.tue.nl/hashclash/Nostradamus/
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: MD5 n'est pas infaillible
Posté par MrLapinot (site web personnel) . Évalué à 4.
Ça ne marche pas : je peux trouver un autre document ET une autre clef qui me redonnent le même document chiffré (du moins pour certains algorithmes de chiffrement). Il faut publier un hash de la clef, et on retombe sur le problème de départ.
[^] # Re: MD5 n'est pas infaillible
Posté par M . Évalué à 3.
Pour le besoin que tu décris, je pense que le scénario le plus simple est le suivant
Non le plus simple est de donner plusieurs hash en même temps (crc, md5, sha1, sha256, ...) [comme le fait debian].
Comme ca même s'il y a des failles sur une fonction de hash et ben les autres sont là.
Et s'il y a des failles sur toute il faut trouver une attaque commune...
# PGP simplement
Posté par X509 (site web personnel) . Évalué à 5.
Tu lui envoies le document chiffré avec GPG, et quand la transaction est fini tu lui transmets la clef Privé.
Tout le monde a droit à la sécurité et à la protection de leur vie privée, pas seulement ceux qui gèrent les sites de commerce électronique.
[^] # Re: PGP simplement
Posté par Nucleos . Évalué à 0.
C'est la bonne solution. J'ai dû lire tous les commentaires précédents pour être certain que personne ne l'avait dit avant. C'est la seule solution à ma connaissance pour être certain de la chose.
# c'est un peu pour ca qu'on utilise MD5 quand meme.
Posté par NeoX . Évalué à 0.
on depose un fichier quelque part avec son MD5
si pendant le transfert ou pendant la manipulation le fichier change, le MD5 calculé sur le nouveau fichier ne correspond alors plus à celui qu'on a stocké.
pour resumer :
- à t0 tu calcule le MD5, et tu envoie le document ET le MD5 à ton client
- à t1 tu envoies le fichier (en fait il l'a deja), il calcule le nouveau MD5
si les deux MD5 sont identiques le fichier n'a pas été modifié...
[^] # Re: c'est un peu pour ca qu'on utilise MD5 quand meme.
Posté par Pierre Tramal (site web personnel) . Évalué à 5.
Alors dans ce cas là, si on envoie le document à t0, même pas besoin de MD5, le tiers peut toujours lancer un diff. Et pendant qu'on y est, à t1 inutile de lui envoyer le même fichier puisqu'il l'a déjà :-)
[^] # Re: c'est un peu pour ca qu'on utilise MD5 quand meme.
Posté par BAud (site web personnel) . Évalué à 3.
hmmmm, pas complètement d'accord avec ta conclusion ;-)
Comme indiqué ci-dessus, c'est plutôt : "si les md5 sont différents alors le fichier a été modifié". La contraposée n'est pas "si les md5 sont égaux, alors les fichiers sont identiques" mais "si les fichiers sont identiques, alors les md5 sont égaux" (ce qui est trivial à démontrer).
# Oui, ou presque
Posté par cowboy . Évalué à 3.
Comme certains l'on déjà dit, le principe de ce que tu demandes est la résistance aux collisions : ayant un message M donc le hashé (empreinte en français) est E, il est impossible de générer M' (différent de M donc) tel que H(M)==E==H(M').
Cependant MD5 est justement vulnérable aux attaques en collision, il est recommandé d'utilisé un algorithme de la famille SHA-2.
Un document de l'ANSSI qui résume les règles concernant ce genre de problèmes : http://www.ssi.gouv.fr/IMG/pdf/RGS_B_1.pdf
[^] # Re: Oui, ou presque
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Question bête est-ce que la fourniture de 2 hashs un peu plus faible est plus sécuriser qu'un hash fort (sur le long terme)?
Par exemple, est-ce que fournir un hash MD5 et un hash SHA-1, serait plus sécurisé qu'un seul hash SHA-2 ?
"La première sécurité est la liberté"
[^] # Re: Oui, ou presque
Posté par Zenitram (site web personnel) . Évalué à 2.
Deux plus sécurisé qu'un seul : oui (faut casser les deux algos on faire une collision qui passe les deux algos)
Plus sécurisé qu'un seul SHA-2 : à démontrer, ça va fortement dépendre des attaques potentielles futures, je ne connais pas assez mais j'imagine que c'est incalculable (par exemple : et si on trouve une méthode pour casser SHA-1 maintenant? Hop avoir deux algos troués ne sera pas mieux qu'un autre algo non troué, mais si on trouve pas de failles ça change...)
[^] # Re: Oui, ou presque
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Si tu as une collision facile à générer sur le MD5, quel est la probabilité d'en trouver une qui collisionne aussi sur SHA-1 ? Même si les 2 algo sont complètement troué, il faudrait trouver des collisions qui s'appliquent aux 2 en même temps, non ?
"La première sécurité est la liberté"
[^] # Re: Oui, ou presque
Posté par Zenitram (site web personnel) . Évalué à 2.
Je pars du principe que si tu as une chance sur 100 de falsifier une signature avec un algo troué, deux algos troué vont donner une chance sur 100*100=10 000. Si l'algo pas troué donne une chance sur 100 000, avoir deux algos troués sera moins efficace qu'un algo pas troué.
Bref, on en reviens toujours à prédire le futur à savoir quel sera la probabilité de trouver une fausse signature avec un algo troué pour savoir quel système (deux algo potentiellement troué vs un algo pas troué) sera meilleur.
Perso je ne sais pas répondre, et je pense que personne ne peut (prédire quel sera le degré de trou des algos troués)
# preuve
Posté par exolin . Évalué à -1.
Il manque quelques paramètres...
La seule chose que tu vas pouvoir prouver avec ton système c'est que tu possédais la version du document t+1 à t.
Ça ne prouve pas que tu n'as pas modifié le document avant t.
Le seul moyen ce serait qu'une autorité de confiance recoive le même document que celui que tu possèdes directement depuis l'émetteur (qui ne peut être toi).
[^] # Re: preuve
Posté par Axone . Évalué à 2.
Et c'est la seule chose qu'il demande, ça tombe bien ;-)
[^] # Re: preuve
Posté par exolin . Évalué à -3.
Et si le document est modifié a t-1 ? :)
[^] # Re: preuve
Posté par Jux (site web personnel) . Évalué à 2.
Il s'en tape puisqu'il veut prouver qu'il ne l'a pas modifiée depuis t.
[^] # Re: preuve
Posté par exolin . Évalué à 1.
Bizarre je vois comme une contrainte qui doit être valide quelque soit l'instant t...
[^] # Re: preuve
Posté par Larry Cow . Évalué à 2.
Il faut forcément un instant t fixe, sinon le problème est insoluble :
[^] # Re: preuve
Posté par exolin . Évalué à 0.
Dans ce cas-là je pense que mettre en place un tel système est un peu inutile car il faut que le destinataire ait déjà confiance dans les données qu'il reçoit de l'autre (vu que l'on génère le document et que l'on envoie l'empreinte).
Si des opérations sont faites à partir du document entre t et t+1 il faudrait voir aussi s'il y a vérification que la version du document correspond au hash t, toujours sans que l'autre entité ne puisse avoir connaissance du document à ce moment-là (vu qu'elle n'y a accès qu'à t+1).
C'est dans ce sens que mon premier message comportait le message
Ce serait à l'émetteur du document de fournir à l'autre entité le hash du document.
[^] # Re: preuve
Posté par Jux (site web personnel) . Évalué à 3.
Comme dit dans un commentaire plus haut, ce système est intéressant pour par exemple faire une mise au concours :
1. Tous les candidats envoie le hash de leur offre
2. Les candidats envoient leurs documents
Ca permet d'éviter que certains candidats aient accès aux offres des autres sans passer par un tiers de confiance.
[^] # Re: preuve
Posté par exolin . Évalué à 1.
Bon ça m'apprendra à faire des commentaire sans avoir le temps de tout lire /o\
Mes plus plates excuses pour mes digressions
# non
Posté par pipo_molo . Évalué à 2.
Les gens sont bien serviables, à te rappeler que MD5 a eu quelques problèmes récemment.
Par contre, faut pas oublier qu'à plus ou moins long terme, aucun système n'est infaillible, et qu'en fonction de la distance entre t et t+1 tu ne disposes peut-être même pas des outils adéquats (algo, puissance de calcul).
Tout ce qu'on sait faire actuellement, c'est estimer la difficulté du problème et viser suffisamment large pour être sûr que les données ainsi protégées ne puissent plus servir une fois la protection cassée.
[^] # Re: non
Posté par pipo_molo . Évalué à 1.
enfin, "ne puissent plus servir une fois la protection cassée" == "soient devenues obsolètes à ce moment".
# Si j'ai bien compris ce que tu veux faire, ta solution ne fonctionne pas.
Posté par phxonx . Évalué à 3.
Très rapidement non,
Si j'ai bien compris ce que tu cherches à faire d'après les commentaires, tu veux pouvoir créer un document dont on peut valider que la personne n'a pas cherché à le modifier depuis l'instant T.
Ton système d'enveloppe cacheté aurait donc tel fonctionnement :
On prend 3 fournisseur A,B et C et un client X
temps T
A créé un doccument dA et envoi le md5 de dA à X
B créé un doccument dB et envoi le md5 de dB à X
C créé un doccument dC et envoi le md5 de dC à X
temps T+1
A envoi dA à X et X valide le md5 de dA
B envoi dB à X et X valide le md5 de dB
C envoi dC à X et X valide le md5 de dC
Problème : si il est (même aujourd'hui, même pour MD5) complexe de faire un collide qui marche sur un document créé par quelqu'un d'autre, il est relativement simple de créer volontaire des documents qui collident les uns avec les autres.
Donc A peut très bien créer dA1, dA2 avec md5(dA1)=md5(dA2), en changeant un élément non significatif du document (par exemple les bits de poids faible d'une image).
Si j'ai bien compris ce que tu cherches à faire, il y a beaucoup plus simple : le chiffrement réversible symétrique.
Chaque personne créé son document, le chiffre avec une clef symétrique et balance la version chiffré au client.
Ensuite au temps t+1 on balance le pass (un truc costaud, genre deux ou trois pages de texte en UTF-8).
Et là le client n'a plus qu'à déchiffrer.
Si ca te casse les pieds de coder ton propre outil, 7zip en mode chiffrement AES-256 avec un mot de passe de 12+ caractères avec les panachages standard (majuscule, minuscule, ponctuation) ca marche bien.
Généralement je dis à mes clients d'utiliser une phrase complète (majuscule au début, point à la fin, espaces entre les mots, mais évitez les accents). C'est déjà bien solide.
[^] # Re: Si j'ai bien compris ce que tu veux faire, ta solution ne fonctionne pas.
Posté par MrLapinot (site web personnel) . Évalué à 2.
Comme dit plus haut, ça ne marche pas : tu peux aussi trouver des collisions sur des algos de chiffrement, puisque tu ne révèles pas la clef.
Je génère un document dA, je le chiffre avec une clef cA, j'envoie le chiffré Blob au client.
Plus tard, je génère un document dB, et j'inverse l'algo de chiffrement pour trouver une clef cB qui donne le même chiffré Blob. J'envoie cB au client, il n'y voit que du feu.
[^] # Re: Si j'ai bien compris ce que tu veux faire, ta solution ne fonctionne pas.
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
A mon avis si tu trouves un moyen de faire ça avec AES pour n'importe quel document dB, tu as la médaille Fields.
"La première sécurité est la liberté"
[^] # Re: Si j'ai bien compris ce que tu veux faire, ta solution ne fonctionne pas.
Posté par MrLapinot (site web personnel) . Évalué à 2.
Le commentaire initial parlait de « le chiffrement réversible symétrique » en général, sans préciser nécessairement AES. En général, c'est faux et il est possible de trouver des collisions (c'est par exemple trivial dans le cas d'un chiffrement XOR, le chiffrement réversible symétrique le plus simple qui soit).
J'insistais donc juste sur le fait que ce n'est pas une meilleure solution en général que les fonctions de hashage, dans les deux cas il faut étudier la sécurité de ton algorithmes aux collisions.
[^] # Re: Si j'ai bien compris ce que tu veux faire, ta solution ne fonctionne pas.
Posté par phxonx . Évalué à 2.
C'est vrai si la clef fait la taille du document ou est plus grande. Par contre Si la clef a une taille inférieure ou très inférieure à la clef, ça va devenir coton de trouver une collision crédible, surtout dans le cas ou on a envoyé le document et pas la clef
Éventuellement si on veut juste modifier des chiffres, et que le document initial n'est pas compressé avec un algo fort, c'est facile de modifier la clef pour modifier la zone voulue, mais si la clef est plus petite que le doc il va y avoir de sacrés effets de bords.
[^] # Re: Si j'ai bien compris ce que tu veux faire, ta solution ne fonctionne pas.
Posté par phxonx . Évalué à 1.
Ben non justement, tu n'envois pas la clef, tu envois le document chiffré (avec un chiffrement tel que pour le casser entre t et t+1 le mec peut se brosser sévère).
A t+1 tu envois la clef. Avec un chiffrement raisonnablement symétrique c'est infalsifiable, avec de l'AES-256 faut déjà se lever de bonne heure. Pour éviter les attaques statistiques en cas de chiffrement symétrique, passer par une couche de compression de haut niveau (7-zip strong avec un catalogue de taille déraisonnable c'est pas mal).
Si tu as des mecs qui sont assez bon pour faire ce genre de choses, et le matos qui leur permet de le faire (c'est pas impossible hein, on doit pouvoir y arriver dans un temps raisonnable (i.e moins d'un an) avec un supercalculateur dernier cri), tu as généralement plus vite fait de t'introduire sur la machine du client de de modifier la clef directement sur son disque dur.
# Combien d'année
Posté par tiot (site web personnel) . Évalué à 1.
Ce qui est cool avec ce système c'est que dès qu'un mathématicien trouve un moyen de générer facilement des collisions alors tout ton système s'écroulera et tu n'auras aucun moyen de prouver que le document était bien le tiens.
Ensuite c'est une question de confiance. Soit tu as confiance à l'autorité et aux moyens de chiffrement pour transférer ton document, soit tu as confiance à un système de hash.
# Oui ça fonctionne
Posté par WhiteCat . Évalué à 2.
Oui ton fonctionnement devrait fonctionner, sauf que c'est pas à toi d'envoyer le 1er MD5, mais à la personne qui t'envoie le document de générer le MD5 elle-même. Sinon comment peut-elle être sûre que tu ne lui envoies pas le MD5 du document déjà modifié ?
Et puis comme d'autres l'ont déjà dit, du SHA-256/512 ou Whirlpool serait mieux que du MD5.
Il existe une super suite logicielle pour générer pas mal de type de sommes de contrôle : http://md5deep.sourceforge.net/
[^] # Re: Oui ça fonctionne
Posté par Axone . Évalué à 1.
Tu lis les énoncés des fois ? C'est lui qui veut prouver qu'il n'a pas modifié un document entre 2 dates.
[^] # Re: Oui ça fonctionne
Posté par WhiteCat . Évalué à 1.
Ba oui et j'y réfléchis même...
Comment peut-il prouver qu'il n'a pas modifié un document avec ses hashs MD5 sachant que c'est lui qui fournit les 2 hashs... il est "juge et partie".
La personne en face lui dira à juste titre : "mais comment je sais que le premier hash que vous me fournissez est le hash du document original et pas celui du document modifié ?".
[^] # Re: Oui ça fonctionne
Posté par ckyl . Évalué à 3.
Version courte: On s'en tape le coquillard.
Version longue: Il veut prouver qu'il possédait déjà un document à un instant T. Cet instant T correspond au moment où il transmet la preuve de possession à bob. Chercher à faire correspondre T à un autre événement n'a aucun sens. Ce qu'il s'est passé avant T on s'en fou, il peut avoir modifié 500x son fichier c'est pas le problème. Par contre une fois T passé, il a transmis son hash et devra fournir un document qui correspond au hash; et donc sauf faille de crypto le document dont il voulait prouver possession à l'instant T.
Quand tu utilises un tiers de confiance ou que tu fais dater&signer une enveloppe scellée, on s'en tape complétement de ce qu'il s'est passé avant que tu scelles l'enveloppe.
Le plus important pour résoudre un problème c'est de savoir lire l’énoncé. Il ne cherche pas à "prouver qu'il n'a pas modifié un document avec ses hashs MD5".
# Impressionnant
Posté par Zenitram (site web personnel) . Évalué à 7.
Ce qui m'impressionne dans la (longue) liste de commentaires, c'est que :
- Peu de monde (il y en a quelques uns, ouf!) hurle quand on parle de MD5. MD5 est troué, déconseillé à utiliser depuis des années (est ce nombre n'est pas 2), mais on y pense encore pour des nouveaux trucs??? Même la "génération suivante" comme SHA-1 est à éviter (pas troué, mais affaibli), c'est dire que MD5 ça date et n'a aucun intérêt en sécurité. SHA-2 (ou RIPEMD ou autre qui n'est pas connu pour être troué ou en défaut bien qu'avec les autres, vu qu'il y a eu moins de tests, la sécurité est plus faible) sont à mettre dans des nouveaux systèmes (humains y compris)
- Pas mal de monde affirme que "si le MD5 de deux fichiers est identique, c'est que les fichiers son identiques". Arghhh. Ca fait pas bondir ça? Faux, faux, faux. On peut juste dire qu'il y a une forte probabilité qu'ils soient identiques et qu'on peut leur faire plus ou moins confiance (très peu avec MD5, fortement avec SHA-256 et encore plus avec SHA-512). la phrase "si le MD5 de deux fichiers est différent, c'est que les fichiers son différents", qui est vrai, n'implique absolument pas que "si le MD5 de deux fichiers est identique, c'est que les fichiers son identiques".
Je sais ça, et je ne suis qu'un curieux de base sur la sécurité (je ne m'occupe pas spécialement de sécurité). Si les moules qui conseillent ici ont du mal avec la sécurité de base, ça fait peur sur le niveau des autres (et on comprend aussi plus facilement tous ces "vols" de base de données...)
Et bonus : personne n'a encore dit que ce journal a plus sa place dans le forum ;-).
[^] # Re: Impressionnant
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Est-ce que 2 hash de 2 systèmes différent serait plus sur qu'un seul ?
Par exemple, le système de cryptage de la TV par satellite repose sur 2 algo de cryptage composé par 2 équipes et qui sont chainé, pour casser ce code, il faut casser les 2 algos qui n'utilise pas les même concept mathématiques.
"La première sécurité est la liberté"
[^] # Re: Impressionnant
Posté par Jérôme Asseray . Évalué à -2.
Hum je suis assez d'accord avec ce point. En effet il faut ajouter une notion de contexte avant de jeter à la poubelle MD5...
Si on peut estimer une collision avec MD5 assez probable, l'algo reste néanmoins pertinent dans certaines conditions.
Quid des performances (temps de calcul/charge CPU)?
On retrouve MD5 dans des solutions de déduplications de données pour répondre au besoin de hachage. Nombre de ces solutions utilisent également en plus des algo de correction d'erreur.
Est-ce que l'utilisation de SHA-512 justifierai la réduction de performance au profit d'une plus grande sécurité (qui reste relative dans ce contexte...) ?
[^] # Re: Impressionnant
Posté par Zenitram (site web personnel) . Évalué à 1.
Performances??? Tu as combien de documents à certifier? Parce que chez moi, à plus de 100 MegaOctets/seconde pour SHA-512 (snas doute limité par le disque), chez du mal à comprendre comment tu va trouver autant de documents...
Bref, fausse raison de garder MD5.
[^] # Re: Impressionnant
Posté par Alex . Évalué à 2.
il ne parlait pas spécifiquement de documents à signer.
On en trouve dans certains système de stockages (beyond raid, un truc non standard, et jsais plus quel fs distribué, et surement plein d'autres exemples). Le temps de calcul et la place prise est à prendre en compte dans ces cas là.
[^] # Re: Impressionnant
Posté par Jérôme Asseray . Évalué à 0.
j'ai pris volontairement l'exemple de la dé-duplication... Tu prends un volume pour lequel tu découpes l'ensemble des fichiers en bloc de 128ko. Le nombre de blocs est alors suffisant pour percevoir une différence de performance/consommation de ressource, non?
[^] # Re: Impressionnant
Posté par Zenitram (site web personnel) . Évalué à 2.
Ton temps d'accès aux données sera bien plus long que le temps de calcul du hash... gagner 0.01% de perfs global au prix de la sécurité (ou non collision), bof comme optimisation.
(et si tu as les moyens d'avoir que du SSD hyper rapide, je pense que tu auras les moyens d'avoir les CPU pour calculer le hash...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.