Discussion :

[Médinoc]

Wow, comme ce code est richement commenté!

[darkwall_37]

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 :

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
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.

[Médinoc]

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.

[darkwall_37]

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.

[Médinoc]

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.

[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.

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.

[Sve@r]

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).

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...

[darkwall_37]

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

Ah si ok; ça vient de monter :p

[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 !
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)

[Sve@r]

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...

Ca évite un read de 0.

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

[Metalman]

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

[Sve@r]

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

Très facile

Code cpp :

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
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 cpp :

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
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 cpp :

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

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);
}

[Metalman]

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 :

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

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
Donc bye bye le feof en effet !
Merci pour mon problème dans le topic d'un autre ! ;P

[Sve@r]

J'ai corrigé mon getline....

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

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

Code c :

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

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);
}

[Metalman]

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 !

[Sve@r]

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

Qu'à cela ne tienne...

Code cpp :

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

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);
}

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...

[Metalman]

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