Discussion :

[Bktero]

Rappelle-moi ce qu'il y a de mal dans ce code, je n'ai pas manipulé de fichier avec C depuis des années

[Matt_Houston]

Le parcours de la chaîne à chaque tour de boucle..?

[Bktero]

Ah oui ! Non mais ça c'est évident, c'était juste pour écrire plus vite le code d'essai

[Matt_Houston]

Toi tu le sais mais pas forcément ceux qui te lisent. Je ne veux pas m'exprimer à la place de Svear mais j'imagine que c'est ce qui l'a fait tiquer. Je pense que le compilo doit remplacer ça vite fait de toute manière..

[Sve@r]

Je pense que le compilo doit remplacer ça vite fait de toute manière..

Ca ce serait intéressant à vérifier. Voire même ouvrir une discussion sur "faut-il faire confiance au compilo".

Je me souviens quand j'ai commencé le C, on me parlait des "register" mais on me disait aussi qu'il valait mieux laisser le compilateur s'en charger. Est-ce qu'aujourd'hui cette tendance (laisser le compilo gérer) doit aussi se déporter sur les fonctions incluses dans les conditions de continuation de boucle ou bien doit-on continuer à veiller nous-mêmes à éviter les appels systématiques en utilisant une varaible intermédaiire ?

Ah oui ! Non mais ça c'est évident, c'était juste pour écrire plus vite le code d'essai

Ouais bien entendu je me doute que t'aurais pas fais ça en vrai. Mais bon, c'était marrant de te taquiner...

[Matt_Houston]

Je ne préconise pas de coder comme un rustre en se reposant sur les optimisations du compilateur. J'aurais moi-même, en production, utilisé un const size_t. Ne serait-ce que pour signifier mon intention au relecteur, pour lui différencier cette implémentation d'une autre qui eût modifié la chaîne à chaque tour de boucle, par exemple. Mais il est certain qu'un compilateur moderne ne passera jamais à côté d'une optimisation aussi triviale.

Je laisse le soin à ceux qui en douteraient de comparer les sorties de -S et -O2 -S.

[dzerko]

Bonjour,

Je reviens vers vous une fois de plus. Je préfère continuer la discussion sur ce post car il y a l'avancement des différents commentaires des personnes ayant répondu.

Mon objectif final est de chiffrer un document via RSA. Pour se faire, j'ouvre mon fichier et lis le contenu du fichier (sois en binaire soit en normal je ne sais pas quel est le mieux). Je recherche à chiffrer le document cependant, il faudrait que j'arrive à séparer par bloc le contenu du fichier afin de chiffrer ces blocs et pas une valeur une par une.

J'aimerais savoir ce que vous préconisez pour cela ? Comment stocker les valeurs du fichier (en binaire ou autre format). Et comment faire pour que ces valeurs soient stockés par bloc.

Pour vous donner une idée, mon code est le suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
long RsaModule (unsigned long e, unsigned long n,int bit) {
    int EncryptedBit;
    EncryptedBit = (bit^e)%n;
    printf("%u", EncryptedBit);
 
    return EncryptedBit;
}
 
void EncryptFile(char * file){ 
 
    int caractere = -1;
    char *NewPathFile = "C:\\Users\\ANNUAL-PROJECT_Win7\\Desktop\\DOSSIER TEST\\Crypted.txt";
    int caracterechiffre;
    FILE *EncryptedFile = fopen(NewPathFile, "wb");
    FILE *ToEncrypt = fopen(file, "rb");
 
    while ((caractere = fgetc(ToEncrypt)) != EOF)
        printf("\nBinaire normal : %u \n", caractere);
        //Appel de ma fonction RSA_Module pour chiffrer le bloc ??
    fclose(EncryptedFile);
    fclose(ToEncrypt);
 
    // Supprime le fichier initial
    //int end = remove(NewPathFile);
}
 
int main() {
 
    unsigned long e = 1267;
    unsigned long d = 3;
    unsigned long n = 2101;  
 
 
 
    EncryptFile("C:\\Users\\ANNUAL-PROJECT_Win7\\Desktop\\DOSSIER TEST\\a chiffrer.txt");
 
}

[Sve@r]

et lis le contenu du fichier (soit en binaire soit en normal je ne sais pas quel est le mieux).

Rien que cette phrase montre que tu ne sais pas ce qu'est un fichier. Parce que moi, j'ai des photos sur mon ordi (des fichiers "jpg" qui sont donc des fichiers binaires) mais je les trouve parfaitement normales !!!
Je te recommande d'aller lire ce post qui traite des fichiers binaires et des fichiers "normaux"...

J'aimerais savoir ce que vous préconisez pour cela ? Comment stocker les valeurs du fichier (en binaire ou autre format)

Tu mélanges tout. Le binaire n'est pas un format de stockage mais un format d'affichage. Il te sert à retranscrire une information pour qu'elle soit compréhensible par celui qui l'utilise. L'information stockée, elle, est stockée sous forme de chiffres (voire même à base de signaux électriques "présents" ou "absent")
Prenons le nombre de doigts de tes deux mains (avec comme hypothèse que ce nombre correspond au nombre standard chez les humains). Ce nombre pourra selon les conventions être représenté comme "A" (base 11, 12, 13, ...), "12" (base 8), "22" (base 4), "20" (base 5), "14" (base 6), "101" (base 3), "1010" (base 2 ou binaire) ou "10" (base 10). Mais quelle que soit cette représentation, ce nombre lui ne change pas.
C'est pareil pour un fichier. Quel que soit ce que tu veux stocker, au final tu n'as que de l'octet. Et cet octet soit il correspond très exactement à ce qu'il faut stocker (c'est par exemple le cas sous Unix/Linux), soit dans un certain cas très précis, il contient des caractères en plus qui (selon moi), ne servent à rien mais qui sont quand-même présents (je veux parler bien entendu du "end of line" des fichiers textes windows représenté par 2 octets là ou un seul aurait suffit ce qui, sur cet OS précis, implique alors de faire une différenciation entre "fichiers textes" et "fichiers binaires").

Je recherche à chiffrer le document cependant, il faudrait que j'arrive à séparer par bloc le contenu du fichier afin de chiffrer ces blocs et pas une valeur une par une.
Et comment faire pour que ces valeurs soient stockés par bloc.

Je ne vois pas trop l'avantage. Déjà, si tu veux regrouper tes octets en "blocs" tu vas vite te retrouver face à la limitation machine.
Prenons un fichier contenant "abcde" (il s'agit ici d'une simple représentation humaine de son contenu qui est plutôt 97, 98, 99, 100 et 101 et encore même là on doit être d'accord sur la convention de représentation de ces nombres pour que toi et moi on comprenne la même chose mais passons sur ce dernier détail car il faut bien faire l'hypothèse qu'on voit tous deux ces nombres de la même façon sinon on ne peut plus communiquer).
Donc tu veux stocker ces 5 nombres dans un bloc. Un bloc de quoi ? Un long ? Ben désolé mais le nombre "097098099100101" est trop gros pour y tenir. Un bloc d'octets ? Ok mais alors tu chiffreras ce bloc octet par octet ce qui reviendra au même que chiffrer ton fichier octet par octet.
Tu es donc limité à au maximum 4 octets dans ton bloc de (on va dire) un long. Mais quand tu transformeras ce long via RSA (il sera élevé à un exposant x) ben je vois mal ce qui va en rester (en fait si je vois plutôt bien car ça coupera ce qui dépasse et il restera un modulo)...

Pour vous donner une idée, mon code est le suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
long RsaModule (unsigned long e, unsigned long n,int bit) {
    int EncryptedBit;
    EncryptedBit = (bit^e)%n;
    printf("%u", EncryptedBit);
 
    return EncryptedBit;
}

Ta fonction est du type "long" (déjà tu l'aurais mis en "unsigned tu gagnais une puissance de 2 et ça je te l'ai déjà dit) et tu fais tes calculs sur un int. Donc en dehors de tous tes problèmes de compréhension, tu risque d'avoir aussi des problèmes de troncature de tes valeurs ou, pire, d'expansion du bit de signe...

[dzerko]

Rien que cette phrase montre que tu ne sais pas ce qu'est un fichier. Parce que moi, j'ai des photos sur mon ordi (des fichiers "jpg" qui sont donc des fichiers binaires) mais je les trouve parfaitement normales !!!
Je te recommande d'aller lire ce post qui traite des fichiers binaires et des fichiers "normaux"...

Effectivement ma vision d'un fichier binaire était différente. Je te remercie pour le lien et je me suis documenter ailleurs en complément.

Tu mélanges tout. Le binaire n'est pas un format de stockage mais un format d'affichage. Il te sert à retranscrire une information pour qu'elle soit compréhensible par celui qui l'utilise. L'information stockée, elle, est stockée sous forme de chiffres (voire même à base de signaux électriques "présents" ou "absent")
Prenons le nombre de doigts de tes deux mains (avec comme hypothèse que ce nombre correspond au nombre standard chez les humains). Ce nombre pourra selon les conventions être représenté comme "A" (base 11, 12, 13, ...), "12" (base 8), "22" (base 4), "20" (base 5), "14" (base 6), "101" (base 3), "1010" (base 2 ou binaire) ou "10" (base 10). Mais quelle que soit cette représentation, ce nombre lui ne change pas.
C'est pareil pour un fichier. Quel que soit ce que tu veux stocker, au final tu n'as que de l'octet. Et cet octet soit il correspond très exactement à ce qu'il faut stocker (c'est par exemple le cas sous Unix/Linux), soit dans un certain cas très précis, il contient des caractères en plus qui (selon moi), ne servent à rien mais qui sont quand-même présents (je veux parler bien entendu du "end of line" des fichiers textes windows représenté par 2 octets là ou un seul aurait suffit ce qui, sur cet OS précis, implique alors de faire une différenciation entre "fichiers textes" et "fichiers binaires").

Je ne vois pas trop l'avantage. Déjà, si tu veux regrouper tes octets en "blocs" tu vas vite te retrouver face à la limitation machine.
Prenons un fichier contenant "abcde" (il s'agit ici d'une simple représentation humaine de son contenu qui est plutôt 97, 98, 99, 100 et 101 et encore même là on doit être d'accord sur la convention de représentation de ces nombres pour que toi et moi on comprenne la même chose mais passons sur ce dernier détail car il faut bien faire l'hypothèse qu'on voit tous deux ces nombres de la même façon sinon on ne peut plus communiquer).
Donc tu veux stocker ces 5 nombres dans un bloc. Un bloc de quoi ? Un long ? Ben désolé mais le nombre "097098099100101" est trop gros pour y tenir. Un bloc d'octets ? Ok mais alors tu chiffreras ce bloc octet par octet ce qui reviendra au même que chiffrer ton fichier octet par octet.
Tu es donc limité à au maximum 4 octets dans ton bloc de (on va dire) un long. Mais quand tu transformeras ce long via RSA (il sera élevé à un exposant x) ben je vois mal ce qui va en rester (en fait si je vois plutôt bien car ça coupera ce qui dépasse et il restera un modulo)...

C'est la mon problème tu me dis qu'en octets, la valeur sera trop grande et j'en suis conscient. C'est pour ça que je cherche une méthode pour chiffrer le fichier de manière correcte afin que ça ne soit pas réversible en supposant que mes clés RSA soient suffisament robuste.

Ta fonction est du type "long" (déjà tu l'aurais mis en "unsigned tu gagnais une puissance de 2 et ça je te l'ai déjà dit) et tu fais tes calculs sur un int. Donc en dehors de tous tes problèmes de compréhension, tu risque d'avoir aussi des problèmes de troncature de tes valeurs ou, pire, d'expansion du bit de signe...

Pour le moment le type de ma fonction n'est vraiment pas ce qui m'interesse sachant que j'ai diminué mes valeurs RSA pour pouvoir faire tenir le tout dans un long. Je suis seulement en phase test et donc n'ai pas besoin pour le moment d'un unsigned.

[Sve@r]

C'est la mon problème tu me dis qu'en octets, la valeur sera trop grande et j'en suis conscient. C'est pour ça que je cherche une méthode pour chiffrer le fichier de manière correcte afin que ça ne soit pas réversible en supposant que mes clés RSA soient suffisament robuste.

Maintenant on entre dans une nouvelle discussion; à savoir quel est ton but réel ? Veux-tu juste t'amuser à faire ton petit RSA pour le plaisir ou bien tu veux vraiment implémenter un RSA "utile" ?
Si c'est un RSA utile je n'en vois pas moi l'utilité. Déjà il y en a un paquet déjà implémentés, en passant par PGP (et son homologue free GPG) et (à priori) je ne vois pas ce que le tien apportera. De plus, une vraie implémentation de RSA étant très longue, généralement on ne l'implémente jamais sur un fichier. On préfère chiffrer le fichier sur un algorithme symétrique (style DES) très rapide et c'est la clef de chiffrement qu'on chiffre par RSA. Le destinaire reçoit la clef DES et le fichier, il déchiffre la clef DES avec sa clef RSA privée et connait ainsi le mot de passe permettant de déchiffrer le fichier.
Mais donc si malgré ces critiques tu veux implémenter un RSA utile, tu devras alors utiliser des grands nombres et passer par une bibliothèque dédiée à ce travail.

Si c'est juste pour le plaisir, alors tu as moins de problèmes. Tu peux très bien travailler avec des unsigned longs et chiffrer tes octets via la méthode que j'ai expliquée ici. Te suffit d'écrire une fonction "chiffrer" et une "déchiffrer" appliquable à un octet puis, une fois que tu l'as bien testée, l'appliquer sur chaque octet du fichier...

Pour le moment le type de ma fonction n'est vraiment pas ce qui m'interesse sachant que j'ai diminué mes valeurs RSA pour pouvoir faire tenir le tout dans un long. Je suis seulement en phase test et donc n'ai pas besoin pour le moment d'un unsigned.

Mauvais argumentaire. Même en phase de test on part quand-même sur un code complètement implémenté (donc avec les bon types) sinon ben les tests partent faussés dès le départ.
Et puis c'est pas compliqué de voir que la fonction est "long" et que la valeur renvoyée étant "int" il faut la changer. En fait, ça aurait dû être un automatisme de déclarer la variable retournée du même type de la fonction...

[dzerko]

Bonjour,

Je ne m'étais pas penché sur d'autres méthodes de chiffrement et il est vrai que je n'avais pas pensé possible la méthode de chiffrer la clé seulement via RSA et de chiffrer le contenu du fichier via une autre méthode. Je vais essayé de me renseigner la dessus.