Probleme dans un programme de cryptage [C] - C - Programmation
Marsh Posté le 24-01-2006 à 19:54:03
Salut,
moi je capte pas grand chose en cryptage decryptage, mais je remarque que ta clé est coder en entier, avec pour plage de valeur -2 milliard a +2 milliard et que message[i] est un char allant de 0 a 255!
Marsh Posté le 24-01-2006 à 20:06:50
En effet en bridant la clé de 0 a 255 ça marche mieux... ^^
Marsh Posté le 25-01-2006 à 10:31:08
Moi j'isolerais de façon plus significative les opérations de saisie du message et de la clef; et les opérations de cryptage/décryptage (qui sont d'ailleurs quasiment les mêmes).
Ensuite, il vaut mieux utiliser l'opérateur "^" plutôt que "+". Le cryptage se fait alors au niveau du bit plutôt que du nombre et il est alors bien meilleur et en plus la même opération permet de crypter ou décrypter
Mais bon, si le but du jeu est juste un exercice de manipulation d'octets et non un projet secret défense, c'est tout à fait suffisant. Mais si vraiment tu veux épater le prof, alors tu peux utiliser un mécanisme de double cryptage.
Voici le principe : tu cryptes ton message clair avec une vrai clef et ça donne un message crypté. Puis tu cryptes ton message crypté avec un message bidon et ça te donne une clef bidon.
Ensuite, si jamais tu es capturé (gros film) et qu'on te force à donner ta clef, ben tu donnes ta clef bidon. En l'associant avec le message crypté, cela donnera un message (bidon) mais personne ne pourra prouver qu'il ne s'agissait pas là du vrai message
Marsh Posté le 25-01-2006 à 13:46:33
Ce que tu dis c'est bien et totalement indéchiffrable je suis d'accord, mais dans ce cas là il faut une clé au moins aussi longue que le message, donc autant se souvenir du message.
Ou alors si c'est pour le transmettre de façon sécurisé, le problème se transforme en comment envoyer la clé
Sinon je précise quil faut dans ce cas une seule clé par message (et sans la faire se répéter) sinon ça se déchiffre en 5 secondes.
Pour faire quelque chose de vraiment costaud sans avoir une clé énorme, actuellement je ne connais pas mieux que lAES. Et une clé peut être utilisé pour chiffrer plusieurs messages sans problème.
Marsh Posté le 25-01-2006 à 18:31:27
Tarabiscote a écrit : Ce que tu dis c'est bien et totalement indéchiffrable je suis d'accord, mais dans ce cas là il faut une clé au moins aussi longue que le message |
Là tu cites le "one time pad" de Gilbert Vernam (utilisé pendant la guerre froide et encore utilisé aujourd'hui pour crypter les communications du téléphone rouge).
Tarabiscote a écrit : Ou alors si c'est pour le transmettre de façon sécurisé, le problème se transforme en comment envoyer la clé
|
L'algorithme de Diffie, Hellman et Merckle permet à deux personnes utilisant chacune un nombre personnel et inconnu de l'autre de générer une clef commune aux deux. Cet algo a été la base des travaux qui ont mené à RSA.
Tarabiscote a écrit : Sinon je précise quil faut dans ce cas une seule clé par message (et sans la faire se répéter) sinon ça se déchiffre en 5 secondes. |
Tout dépend de la taille de la clef.
Tarabiscote a écrit : Pour faire quelque chose de vraiment costaud sans avoir une clé énorme, actuellement je ne connais pas mieux que lAES. Et une clé peut être utilisé pour chiffrer plusieurs messages sans problème. |
Idem réponse précédente. Mais bon, je crois qu'on dépasse un peu le cadre du TP (s'il s'agit bien d'un TP)...
Marsh Posté le 25-01-2006 à 20:19:18
Sve@r a écrit : Là tu cites le "one time pad" de Gilbert Vernam (utilisé pendant la guerre froide et encore utilisé aujourd'hui pour crypter les communications du téléphone rouge). |
Téléphone rouge je pense pas mais par contre ça métonnerai pas pour la commande de lancement de la bombe nucléaire
Sve@r a écrit : L'algorithme de Diffie, Hellman et Merckle permet à deux personnes utilisant chacune un nombre personnel et inconnu de l'autre de générer une clef commune aux deux. Cet algo a été la base des travaux qui ont mené à RSA. |
Ok, mais il ne faudrait pas essayer de créer une clé de la taille du message avec. (ces algos ont une très forte complexité, cest ce qui fait quils peuvent tenir un bon moment, mais ils ne sont pas infaillibles).
Sve@r a écrit : Tout dépend de la taille de la clef. |
Et du nombre de messages, si tu envoies 100 messages avec une telle clé peut importe la longueur, ça se décrypte sans problème.
Sve@r a écrit : Idem réponse précédente. Mais bon, je crois qu'on dépasse un peu le cadre du TP (s'il s'agit bien d'un TP)... |
Je disais pas qu'il fallais faire ça pour le TP, c'était juste histoire de démonter ton histoire de film , ça risque pas d'arriver avec ce genre d'algo.
Marsh Posté le 25-01-2006 à 22:44:35
Tarabiscote a écrit : Je disais pas qu'il fallais faire ça pour le TP, c'était juste histoire de démonter ton histoire de film , ça risque pas d'arriver avec ce genre d'algo. |
Non, j'ai expliqué le double cryptage juste pour montrer l'idée et les possibilités qu'on peut en faire (le logiciel "TrueCrypt" sous Licence GPL disponible pour Zindoz et Linux offre justement cette possibilité => http://www.truecrypt.org). Evidemment que sur un algo style "cryptage de Jules César" c'est même pas la peine d'y songer. Mais l'algo peut changer...
Marsh Posté le 29-01-2006 à 13:37:16
Comment adapter le systeme de cryptage pour ce style de programme (je veux crypter hEdit):
Main.c
Code :
|
resource.h
Code :
|
resource.rc;
Code :
|
Marsh Posté le 24-01-2006 à 19:45:55
Voici un programme de cryptage:
Mais voilà, je ne comprends pas pourquoi, quand je crypte puis décrypte un mot avec le bonne clé, le résultat est faux. Je ne sais pas si celà vient de l'opération de cryptage ou de décryptage, ou même des deux.
Message édité par Pcsnake le 24-01-2006 à 19:46:42
---------------
Non pas maintenant