implémentation algorithme XOR

Bonjour,

Je me suis mis à implémenter l'algorithme XOR.
Quand j'ai fais mes algos, je n'ai pas pensé au fait qu'un caractère pouvait être transformé en caractère EOF qui vaut je crois -1 sous Windows.
Une fois le fichier crypté, le résultat est enregistré dans un fichier texte ainsi que la clé de cryptage.

Or si dans l'un ou dans les deux fichiers, un caractère est changé en EOF avant la fin réelle du fichier, ils deviennent donc tronqués au décryptage et celui ci est incomplet.

En gros ce que je fais:
Je récupère le fichier à crypter dans un string.
Je convertis en binaire signé chaque caractère de la string.
J'applique une clé xor de la taille de l'ensemble de la string convertis en binaire signé.
Je convertis en caractères les binaires signés "xoré" et la clé.
J'enregistre la clé et le résultat du cryptage dans un fichier texte.

Quelqu'un a t-il une idée pour remédier à cela ?
Sinon je pourrais coller dans les fichier textes le code binaire des char au lieu du char lui même mais bon cela occupe 8*plus de place et çela procure moins d'effet qu'un ramassis de caractères imbitable.

Je mets le code source en PJ si quelqu'un souhaite regarder.
Projet codeblocks complié sous windaub.

Merci d'avance.

Bonjour,

EOF équivaut généralement à (int)-1 et n'est pas inscrit dans le fichier ou le flux.
EOF est juste une valeur que retourne les fonctions de lecture pour signaler la fin du fichier (ou une erreur).

Je ne penses donc pas que ton problème vienne de là.

Au cas où tu peux toujours faire :

Code:

---

1 2	int caractere; char caractereAEcrire = (char)caractere;

---

Ok merci pour ta réponse.
J'ai remarqué cependant que fscanf s'arrête d'enregistrer le fichier en mémoire lorsqu'il tombe sur ce caractère :

Code:

---

�)ZÁ�Çûm—ici}èÉR_,â…)-¤¡öãȹ?Ô¿mECI•ËÉwL�*ˆªý*ó³

---

Il y a "ici" un caractère que je vois dans le fichier texte, mais une fois copié ici, on ne le voit plus. Cependant, quand on passe à la flêche, il faut appuyer deux fois pour passer au caractère suivant, ce qui prouve bien qu'il y a bien un caractère.

On peut le voir sur l'image ci dessous :

http://img402.imageshack.us/img402/3601/xored.png

Dans ce cas là, le fichier s'arrête au deuxième caractère (le carré).

Il faudrait ouvrir ton fichier avec un éditeur de texte pouvant afficher l'hexadécimal pour voir la valeur de ce caractère.
Peut-être est-ce un EOT (End Of Transmission) que fscanf interprète (?).
Mais pour lire un fichier binaire, n'oublie pas de l'ouvrir avec l'option "b" lors du fopen (cf man fopen) pour la compatibilité.
Et je n'ai pas vu comment tu utilise fscanf, mais peut-être serait-il préférable d'utiliser un fread ?

Comme ça.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

char *file_to_string_1( const char *p ) { char c; unsigned long long int i = 0; char *s = allocate_1D_c( file_length(p)+1 ); FILE *f = file_open(p,"r"); while( fscanf(f,"%c",&c) != EOF ) { s[i] = c; i++; } file_close(f); return s; }

---

J'y ai pensé mais fread s'arrête quand il tombe sur EOF aussi ?
Ca ne va pas régler le problème ?!

http://img856.imageshack.us/img856/3601/xored.png

fread ne peut pas tomber sur EOF car EOF n'est pas présent dans un fichier.

Sinon, je pense qu'un fgetc serait bien plus approprié qu'un fscanf(f, "%c", &c).
Comme tu sembles être sous windows, ouvre bien ton fichier avec FILE *f = file_open(p,"rb");

Si tu ouvres un fichier qui n'est pas du texte, sous Windows, avec l'option "r", alors la lecture sera faussée de nombreuses manières y compris quant à la fin du fichier.
Je te conseille d'ouvrir le fichier en lecture non textuelle, soit "rb" ...

Edit : Argggh ! Neckara a publié plus vite ! ;)

c'est un fichier texte que j'ouvre.
Quand j'enregistre le code binaire de la clé et du xor sous forme de chaine, ca marche.
Mais bon ce n'est pas ce que je veux.
J'ai rajouté b au mode d'ouverture mais ça plante à l'execution, SIGTRAP.
Qu'est ce que ça va changer le mode rb à la façon d'utiliser fscanf ?
Je peux toujours prendre des caractères ?

Sous Linux non mais sous Windows, si on ouvre le fichier en mode texte, Windows ignorera les caractères non-imprimables.

Sinon il me semble que SIGTRAP est normalement émis lors de l'utilisation d'un débogueur lors qu'on arrive à un point d'arrêt.

C'est normal qu'un fichier texte bug si on l'ouvre en mode rb si on utilise fscanf car on cherche EOF qui n'existe pas non ?

On ne recherche jamais EOF, EOF n'est jamais présent dans un fichier ou dans un flux. EOF n'est qu'une valeur retournée par les fonctions de lecture pour avertir d'une erreur comme la fin de fichier.

La seule différence avec le mode texte sous Windows, à ma connaissance, c'est que Windows ne prend pas en compte les caractères non-imprimables lors de la lecture en mode texte.

Citation:

---

Envoyé par darkwall_37

J'y ai pensé mais fread s'arrête quand il tombe sur EOF aussi ?
Ca ne va pas régler le problème ?!

---

Salut
fread() est plus adapté à la lecture d'informations "en vrac" (comme c'est le cas d'un flux crypté) que fscanf() adapté, lui, à la lecture de flux texte "formaté" (comme pourrait l'être un CSV par exemple).

fread() renvoyant le nombre d'éléments réellement lus, tu peux détecter la fin de fichier quand ce nombre renvoyé est inférieur au nombre d'éléments demandés...

Ah okay, merci pour vos éclaircissements.
Donc probablement que ce caractère n'est pas imprimable, ce pourquoi la lecture avec fscanf d'un fichier texte sous windows provoque cette erreur.
Je potasse tout ça.

Merci

Citation:

---

Neckara : La seule différence avec le mode texte sous Windows, à ma connaissance, c'est que Windows ne prend pas en compte les caractères non-imprimables lors de la lecture en mode texte.

---

Le mode "rb" en lecture d'un fichier non texte sous Windows est essentiel, car en mode "r" il ne passe pas seulement les caractères non affichables mais s'arrête aussi avant la fin, en rencontrant un zéro par exemple, et attend des fins de ligne de type CR LF ... :bug:

Citation:

---

darkwall_37 : c'est un fichier texte que j'ouvre.

---

Bah, non, s'il est crypté, ce n'est plus un fichier texte, il n'y a qu'à voir la copie d'écran du fichier dans le bloc-note ! :scarymov:
fichier texte = fichier à plat ne comportant que des caractères affichables ou de formatage (TAB, CR, LF) ...

Oui c'est pas faux. Mais je me suis mépris quant à ce qu'était un fichier texte. Merci pour les précisions.

Concernant fread, il bloque de même, quand je récupère la taille du fichier ouvert en rb, il s'arrête comme fscanf, au même endroit.
Ou alors tu parlais de faire encore autrement et je ne t'ai pas compris.

Code:

---

1 2 3

fseek (pFile , 0 , SEEK_END); lSize = ftell (pFile); rewind (pFile);

---

Citation:

---

Envoyé par darkwall_37

Oui c'est pas faux. Mais je me suis mépris quant à ce qu'était un fichier texte. Merci pour les précisions.

Concernant fread, il bloque de même, quand je récupère la taille du fichier ouvert en rb, il s'arrête comme fscanf, au même endroit.
Ou alors tu parlais de faire encore autrement et je ne t'ai pas compris.

Code:

---

1 2 3

fseek (pFile , 0 , SEEK_END); lSize = ftell (pFile); rewind (pFile);

---

---

Pas besoin de récupérer la taille. Un truc de ce genre devrait le faire

Code:

---

1 2 3 4 5 6 7

int nb; char buf[1000]; while ((nb=fread(pFile, 1, 1000, buf)) > 0) { xor_decode(buf, nb); fwrite(stdout, 1, nb, buf); }

---

Bien entendu, à toi de programmer xor_decode pour décrypter les nb octets situés dans buf...

Ah si j'ai saisi ce que tu disais et ça semble marcher !

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#include <stdio.h> #include <stdlib.h>   int main() { FILE *f = fopen("c:\\xored.txt","rb"); char *buffer = malloc(sizeof(char)); while (0<fread(buffer,1,sizeof(char),f)) printf("%s",buffer),getchar();   fclose(f); free(buffer); return 0; }

---

EDIT : AH trop rapide tu es !
Ce n'est pas conseillé comme façon de faire de manière générale je suppose ? Cela m'a l'air d'être la façon la plus simple et la plus sûre pour lire un fichier (binaire+fread) et ce n'est pourtant pas ce qui est enseigné en premier comme méthode.

Merci à tous pour vos réponses et vos explications.
L'utilisation du mode d'ouverture rb ainsi que l'utilisation de fread & fwrite a réglé les problèmes décris dans ce post.

Il faut que je reprenne le code pour l'améliorer à tout point de vue. En tous cas pour le moment après avoir lancé des 1.000.000 de cryptages à la suite, l'entrée = la sortie à chaque fois :p.

Citation:

---

Envoyé par darkwall_37

Ah si j'ai saisi ce que tu disais et ça semble marcher !

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#include <stdio.h> #include <stdlib.h> int main() { FILE *f = fopen("c:\\xored.txt","rb"); char *buffer = malloc(sizeof(char)); while (0<fread(buffer,1,sizeof(char),f)) printf("%s",buffer),getchar(); fclose(f); free(buffer); return 0; }

---

EDIT : AH trop rapide tu es !
Ce n'est pas conseillé comme façon de faire de manière générale je suppose ? Cela m'a l'air d'être la façon la plus simple et la plus sûre pour lire un fichier (binaire+fread) et ce n'est pourtant pas ce qui est enseigné en premier comme méthode.

---

Hum. Déjà faire un malloc de 1 char c'est un peu absurde vu que si tu déclares un simple char c'est déjà un char qui t'est directement réservé. Mais ensuite traiter ce char comme une chaine de caractères c'est le clash assuré à plus ou moins long terme. Et dernier détail, fread() veut en premier la taille d'un élément et en second le nombre d'éléments à récupérer. Toi tu l'as mis dans l'autre sens. Là c'est pas grave vu que les deux valeurs sont à 1 mais si ensuite tu veux faire évoluer ton code (remarque dans mon exemple de ce matin j'ai inversé le buffer et le flux :aie:)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

#include <stdio.h> #include <stdlib.h>   int main() { FILE *f = fopen("c:\\xored.txt","rb"); char c;   while (fread(&c,sizeof(char), 1,f) > 0) fwrite(&c, sizeof(char), 1, stdout);   fclose(f); return 0; }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#include <stdio.h> #include <stdlib.h>   #define SZ_BUF (1000)   int main() { FILE *f = fopen("c:\\xored.txt","rb"); char buf[SZ_BUF]; int nb;   while ((nb=fread(buf,sizeof(char), SZ_BUF,f)) > 0) fwrite(buf, sizeof(char), nb, stdout);   fclose(f); return 0; }

---

Oui en effet, mais j'ai refais les fonctions au propre et je l'avais corrigé. Je suis allé lire un petit man entre temps :X. Merci pour ton oeil intraitable quoiqu'il en soit :p.
EDIT : je vais rajouter le retour de fread (nb) que j'ai manqué. Merci.

Pour le char, totalement absurde je confirme. Je suis absurde, j'aime l'absurdité, j'assume :pan::massacre:

Wow, comme ce code est richement commenté!

Citation:

---

Envoyé par Médinoc

Wow, comme ce code est richement commenté!

---

IRON-E :p


En fait, je me suis aperçu que je m'embêtais très largement à passer par le binaire pour faire mes opérations.

Je suis allé au plus simple je pense. Par contre je ne comprends pas pourquoi lorsque je "crypte" un fichier de 20Mo par exemple, je vois la quantité de mémoire utilisé par le programme monter à 800Mo. Comment est-ce possible ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

void fxor(const char *file_path) { FILE *f = file_open(file_path,"rb"); FILE *f_key = file_open("c:\\key","wb"); FILE *f_xor = file_open("c:\\out","wb"); char buffer[3][1]; int r_fread=0; t_binw *random_byte = NULL;   while ((r_fread=fread(&buffer[0],sizeof(char), 1,f)) > 0) { random_byte = binw_create_random(8); buffer[1][0] = bin_to_dec(random_byte->v,8); binw_destroy(random_byte); fwrite(&buffer[1], sizeof(char), r_fread, f_key), buffer[2][0]=buffer[0][0]^buffer[1][0]; fwrite(&buffer[2], sizeof(char), r_fread, f_xor); }   file_close(f_key); file_close(f_xor); file_close(f); }     void frox(const char *xored, const char *key) { FILE *f_key = file_open(key,"rb"); FILE *f_xor = file_open(xored,"rb"); FILE *f_rox = file_open("c:\\xored","wb"); char buffer[3][1]; int r_fread[2][1];   while ((r_fread[0][0]=fread(&buffer[0],sizeof(char), 1,f_xor)) > 0) { r_fread[1][0]=fread(&buffer[1],sizeof(char), 1,f_key); if (r_fread[0][0]==r_fread[1][0]) { buffer[2][0]=buffer[0][0]^buffer[1][0]; fwrite(&buffer[2], sizeof(char), 1, f_rox); } }   file_close(f_key); file_close(f_xor); file_close(f_rox); }

---

EDIT : Fuite mémoire dans un appel d'appel de la fonction dec_ton bin, autant pour moi.

C'est un one-time pad, ton cryptage? Ta clé fait la même longueur que le fichier...

PS: J'ai du mal à comprendre pourquoi tu utilises un tableau de trois tableaux de un byte plutôt qu'un simple tableau de trois bytes. Aussi, &buffer[0] possède le type char (*)[0], mais tu passes sizeof(char) comme taille. Même si ça devrait en théorie avoir la même valeur, c'est une incohérence.

C'est une erreur de ma part, j'ai testé les deux et après le copié collé j'ai oublié d'enlever l'opérateur &.

Oui la clé fait la taille du fichier. Ça peut faire des grosse clés en effet.
C'est pour du test, mais je suis en train de refaire le multi-padding.
Je vais regarder ce qui est le plus robuste, une énorme clé en otp ou une clé moindre paddée plusieurs fois. Ou une clé énorme paddée plusieurs fois. Il faut dire que l'espace de stockage n'est plus tellement un problème de nos jour.

Dans tous les cas, le OTP est un cryptage à secret partagé, donc "seulement aussi sûr que sa clé". Maintenant tu as un nouveau problème: Transmettre ta clé de manière sécurisée.

Oui c'est vrai, mais j'ai presque finit RSA avec GMP pour crypter la clé si je dois la faire passer sur un réseau. J'ai encore quelque petit soucis mais ça sent la fin.

Cela dit, c'est pour trimbaler ce qu'il y a sur ma clé USB. A moins que le contenu de ma clé intéresse la NASA, je doute que X reverse une clé XOR otp même de 10Mo.
La clé, elle reste sur le net à disposition sur un hébergeur sécurisé. Où que j'aille je peux décrypter comme ça.

Citation:

---

Envoyé par darkwall_37

Je vais regarder ce qui est le plus robuste, une énorme clé en otp ou une clé moindre paddée plusieurs fois. Ou une clé énorme paddée plusieurs fois.

---

Une clef paddée plusieurs fois revient à faire du Vigenère. Or ce type de code a été cassé par Charles Babbage au XIX°. Il a d'abord récupéré la longueur de la clef puis il a fait de l'analyse de fréquence sur chaque partie du message crypté avec la même lettre (même lettre due au padding).

D'un point de vue cryptanalyse, le otp est la méthode absolue et inattaquable. Malheureusement, comme le dit Medinoc, le otp reporte le problème de la transmission du message à la transmission de la clef qui est de la même longueur (donc problème équivalent).

Citation:

---

Envoyé par darkwall_37

Oui c'est vrai, mais j'ai presque finit RSA avec GMP pour crypter la clé si je dois la faire passer sur un réseau. J'ai encore quelque petit soucis mais ça sent la fin.

---

Ben comme je le dis plus haut, tant qu'à crypter par une méthode 2 une clef aussi longue que le texte, autant crypter alors juste le texte et laisser tomber la clef...

Citation:

---

Ben comme je le dis plus haut, tant qu'à crypter par une méthode 2 une clef aussi longue que le texte, autant crypter alors juste le texte et laisser tomber la clef...

---

Désolé, je n'ai pas compris cette partie :oops:

Ah si ok; ça vient de monter :p

Pour la partie fread, tu peux utiliser la terrible fonction feof qui renvoie 0 tant que l'on n'est pas à la fin du fichier !
Ca évite un read de 0. ;)

Et surtout : chiffrer, pas crypter !

Pour la transmission de clé, il y a quelques méthodes du côté asymétrique...
Le mieux étant d'utiliser en premier un chiffrement asymétrique pour échanger une clé symétrique, puis de faire une communication chiffrée avec la clé symétrique.
La force de ce système est :
Peu de message chiffré avec de l'asymétrique, donc peu d'attaques possibles.
Le symétrique étant plus rapide, les messages longs seront calculés puis transmis assez vite.
La résistance des chiffrements est "temporaire" : plus les machines montent en puissance, plus les chiffrements deviennent faibles.
Donc ton application de transmission deviendra obsolète dans N années (mais je ne peux pas le prévoir), et à ce moment là, la seule solution est d'augmenter la longueur de clé et/ou changer d'algorithme (si de nouveaux solides sont écrits)

Citation:

---

Envoyé par Metalman

Pour la partie fread, tu peux utiliser la terrible fonction feof qui renvoie 0 tant que l'on n'est pas à la fin du fichier !

---

Non. Ca indique, une fois que la lecture ne se fait plus, si l'arrêt de lecture est dû à une fin de fichier ou autre chose (une erreur).
Donc si un fichier fait 1000 car. et qu'on lit 1000 car., on a atteint la fin de fichier mais feof() continue à renvoyer 0 et continuera ainsi tant qu'on aura pas demandé un accès de plus...

Citation:

---

Envoyé par Metalman

Ca évite un read de 0. ;)

---

Ben justement, c'est le read de 0 qui permet de sortir de la boucle...

woups....
J'avais refait un p'tit getline le WE dernier, ca marche pas trop mal....
Mais je n'ai jamais testé en fin de fichier maintenant que tu me dis ça !
Graaaah... merci de me corriger !


EDIT : Mouais....

The function feof() tests the end-of-file indicator for the stream
pointed to by stream, returning nonzero if it is set. The end-of-file
indicator can only be cleared by the function clearerr().

The function ferror() tests the error indicator for the stream pointed
to by stream, returning nonzero if it is set. The error indicator can
only be reset by the clearerr() function.

En effet ça n'est pas génial de boucler sur feof, même si ça marche dans ce que je faisais

Citation:

---

Envoyé par Metalman

Mais je n'ai jamais testé en fin de fichier

---

Très facile

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

int main() { char buf[1000]; FILE *fp; char *c; fp=fopen("fichier_quelconque", "r") while (feof(fp) == 0) { fgets(buf, 1000, fp);   // On enlève le '\n' qui gêne la visibilité (mais ne nuit en rien à la démo) if ((c=strrchr(buf, '\n')) != NULL) *c=0;   // L'affichage qui tue printf("j'ai lu la ligne [%s]\n", buf); } fclose(fp); }

---

On rajoute les quelques #include que j'ai omis (tapé en live), on compile et on exécute. Et là on verra qu'on aura un "printf" de plus que de lignes réelles. Parce que le dernier fgets() valide n'aura rien changé au retour de feof(), on a un fgets de trop.

Et l'exemple inverse

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

int main() { char buf[1000]; FILE *fp; char *c; fp=fopen("fichier_quelconque", "r") while (fgets(buf, 1000, fp) != NULL) { // On enlève le '\n' qui gêne la visibilité (mais ne nuit en rien à la démo) if ((c=strrchr(buf, '\n')) != NULL) *c=0;   // L'affichage qui tue printf("j'ai lu la ligne [%s]\n", buf); } fclose(fp); }

---

Et là, autant de printf que de lignes réelles. Parce que là c'est le fgets() qui est testé et donc lorsqu'il ne lit plus rien, il sort.

Toutefois, à ta décharge, je t'accorde que dans les deux exemples il y a toujours un fgets() de plus que de lignes réelles. Simplement dans le second c'est le fgets qui sert de test et non feof (qui, lui, pourra ensuite indiquer si fgets() a raté à cause d'un eof ou pas)

suite de l'exemple

Code:

---

1 2 3 4 5 6 7 8

printf("j'ai lu la ligne [%s]\n", buf); } if (feof(fp)) printf("fin de fichier\n"); else printf("hum, gros pb (voir du coté de strerror() pour plus de détails)\n"); fclose(fp); }

---

J'ai corrigé mon getline....

Je vérifie la len que me renvoie mon fread et je le compare à la taille que je lui ai demandé de lire....
Tant qu'elle est pareille, ça boucle...
Pour éviter les bêtises :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

# define BUF_SIZE 512   char buf[BUF_SIZE]; size_t len;   len = fread(buf, sizeof (char), BUF_SIZE, stream); while (len == BUF_SIZE) { ... len = fread(buf, sizeof (char), BUF_SIZE, stream); }

---

Ne pas oublier de faire le read "avant" la boucle, et de le faire "en dernier" dans la boucle :P
Donc bye bye le feof en effet !
Merci pour mon problème dans le topic d'un autre ! ;P

Citation:

---

Envoyé par Metalman

J'ai corrigé mon getline....

Ne pas oublier de faire le read "avant" la boucle, et de le faire "en dernier" dans la boucle :P

---

Pourquoi 2 read ??? La méthodologie qu'on apprend à l'école c'est bien mais ensuite faut savoir utiliser les outils de son langage. Un bon programmeur respecte les règles, un programmeur brillant les transgresse parfois :ccool:

Code:

---

1 2 3 4 5 6 7

while ((len=fread(buf, sizeof (char), BUF_SIZE, stream)) > 0) { // ici len contient le nb de caractères lus, on peut s'en servir comme on veut   //par exemple pour faire comme un "cat" Unix ou un "type" Windows fwrite(buf, sizeof (char), len, stdout); }

---

Haha, j'ai toujours détesté faire une affectation dans une boucle...
Ca me gêne dans la lecture, et du coup... je me dis que d'autres seront aussi gênés...

Donc j'évite, mais en effet ça réduit le nombre de lignes !

Citation:

---

Envoyé par Metalman

Haha, j'ai toujours détesté faire une affectation dans une boucle...

---

Qu'à cela ne tienne... 8-)

Code:

---

1 2 3 4 5 6 7 8

while (1) { len=fread(buf, sizeof (char), BUF_SIZE, stream); if (len == 0) break;   // le reste c'est pareil fwrite(buf, sizeof (char), len, stdout); }

---

;)

Citation:

---

Envoyé par Metalman

et du coup... je me dis que d'autres seront aussi gênés...

---

Non quand-même pas. Une expression remplie de ++ ** [] -> ?: >> << mélangés dans tous les sens je veux bien mais là ça reste encore assez simple...

Justement... ça démarre par une affectation... ça finit avec une ternaire contenant 2 index post et pré incrémentés dans la condition.... (oui oui j'ai vu ça une fois...)

Mais je pense que ça ira, merci des conseils :P