begin process at 2010 09 06 11:59:00
  Trouver un code source :
 
dans
 
Accueil > 

Code

 > 

Sécurité & Cryptage

 > CRYPTAGE DE FICHIER AVEC LA FONCTION XOR SUR N BITS

CRYPTAGE DE FICHIER AVEC LA FONCTION XOR SUR N BITS


 Information sur la source

Note :
8,67 / 10 - par 3 personnes
8,67 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10
Catégorie :Sécurité & Cryptage Niveau :Débutant Date de création :28/03/2005 Date de mise à jour :28/03/2005 03:06:20 Vu :8 859

Auteur : bapt1080

Ecrire un message privé
Commentaire sur cette source (10)
Ajouter un commentaire et/ou une note

 Description

Ce code sert a crypter un fichier donné vers un autre fichier cible donné et avec une clef de la longueur que vous voulez(16 à inf bits).
exemple : $cdxor source.txt crypter.txt key
Comme il s'agit d'un cryptage xor, il suffit de faire l'inverse pour decrypter.
exemple : $cdxor crypter.txt source.txt key

Ce cryptage est incassable si la clef est aussi longue (ou plus longue mais seul une partie sera utilisée) que le message (fichier) à coder (cas parfait) et est très dur à casser si la clef est tres longue (se repete le moins possible, car un caractere de la clef code la taille d'un caractere de la source, donc la clef est réutilisée comme ecrite sur un anneau).

Cependant il est possible (mais tres dur) de cracker une clef si on connait le type de fichier (structure identique pour tout les mp3 par exemple), alors evitez de mettre l'extention du fichier source au fichier crypté pour plus de sécurité.

Je n'ai pas géré les erreurs comme celle d'ouverture de fichier car je l'ai codé assez vite...
Mais je vous laisses le faire ;-)

Voila, je suis ouvert a tout commentaires ou toutes questions.
Cryptez bien! :-)

Source

  • #include <fstream>
  • #include <iostream>
  • using namespace std;
  • void edxor(char*scrfile,char*codfile,char cKey[])
  • {
  • int cpt=0,curs=0,length,pos=0;
  • char * buffer;
  • bool go=true;
  • //j'ouvre les deux fichiers source et destination
  • fstream In(scrfile,ios::in|ios::binary);
  • fstream Out(codfile,ios::out|ios::binary);
  • //je recupere la taille du fichier source
  • In.seekg (0, ios::end);
  • length = In.tellg();
  • In.seekg (0, ios::beg);
  • //gestion affichage
  • if(length<40)go=false;
  • //j'alloue la memoire de la taille du fichier
  • buffer = new char [length];
  • //je met tout le fichier dans le buffer
  • In.read (buffer,length);
  • In.close();
  • //gestion affichage
  • cout<<"0% 50% 100%\n";
  • //boucle qui va effectuer sur chaque caractere le xor
  • //avec le caractere correspondant de la clef
  • while(cpt<length)
  • {
  • buffer[cpt++]^=cKey[curs++];
  • if(curs>=strlen(cKey))
  • curs=0;
  • //gestion affichage
  • pos++;
  • if(go)if(pos>=(length/40))
  • {
  • cout<<"#";
  • pos=0;
  • }
  • }
  • //gestion affichage
  • if(!go)cout<<"#########################################";
  • //j'ecrit le buffer qui a subit le xor dans le fichier de destination
  • Out.write (buffer,length);
  • Out.close();
  • }
  • //$>cdxor infile outfile key
  • int main(int argv,char ** argc)
  • {
  • //test des arguments
  • if(argv!=4)
  • cout<<"$>cdxor infile outfile key";
  • else
  • {
  • cout<<" Cryptage xor par B.RENEL\n";
  • edxor(argc[1],argc[2],argc[3]);
  • }
  • return 0;
  • }
#include <fstream>
#include <iostream>

using namespace std;

void edxor(char*scrfile,char*codfile,char cKey[])
{
	int cpt=0,curs=0,length,pos=0;
	char * buffer;
	bool go=true;

	//j'ouvre les deux fichiers source et destination
	fstream In(scrfile,ios::in|ios::binary);
	fstream Out(codfile,ios::out|ios::binary);

	//je recupere la taille du fichier source
	In.seekg (0, ios::end);
	length = In.tellg();
	In.seekg (0, ios::beg);

	//gestion affichage
	if(length<40)go=false;

	//j'alloue la memoire de la taille du fichier
	buffer = new char [length];

	//je met tout le fichier dans le buffer
	In.read (buffer,length);
	In.close();

	//gestion affichage
	cout<<"0%                50%               100%\n";

	//boucle qui va effectuer sur chaque caractere le xor
	//avec le caractere correspondant de la clef
	while(cpt<length)
	{
		buffer[cpt++]^=cKey[curs++];
		if(curs>=strlen(cKey))
			curs=0;

		//gestion affichage
		pos++;
		if(go)if(pos>=(length/40))
		{
			cout<<"#";
			pos=0;
		}
	}

	//gestion affichage
	if(!go)cout<<"#########################################";

	//j'ecrit le buffer qui a subit le xor dans le fichier de destination
	Out.write (buffer,length);
	Out.close();
} 


//$>cdxor infile outfile key
int main(int argv,char ** argc)
{
	//test des arguments
	if(argv!=4)
		cout<<"$>cdxor infile outfile key";
	else
	{
		cout<<"       Cryptage xor par B.RENEL\n";
		edxor(argc[1],argc[2],argc[3]);
	}
	return 0;
}

 Conclusion

Le code se compile avec n'importe quel compilo C++ comme g++ par exemple.


 Historique

28 mars 2005 03:00:40 :
mise a jour du commentaire
28 mars 2005 03:02:50 :
maj code
28 mars 2005 03:06:20 :
maj code

 Sources de la même categorie

Source avec Zip Source avec une capture CRYPTEUR-DÉCRYPTEUR-IP par antho974
Source avec Zip Source avec une capture ELGAMALCIPHER par CHAR As Human
Source avec Zip CRYPTER-DECRYPTER EN UTILISANT L'ALGORITHME DE CESAR par Antoinejdu44
Source avec Zip CRYPT-O-MATIC "DARKCHOCOLATE" par FrancoisGauthier
Source avec Zip CREEP SECURITY ALGORITHM par nanonavich

Commentaires et avis

Commentaire de Urgo le 28/03/2005 04:49:12

Y'a des couches tard par ici... :)

Là je suis un peu fracassé donc je regarderai ton code de plus près après une bonne "demi-nuit" de sommeil ;)

ciao
Urgo

Commentaire de Kirua le 29/03/2005 08:27:25

Est-ce que pour un tout petit peu compliquer la faille due à la répétition de la clef, tu ne peux pas essayer d'imaginer un facteur lié à la position du caractère dans la chaîne? Bon, bien sûr, ce facteur doit être dépendant de la clef et ou du message, ça peut pas être statique (faut pas juste faire car ^ cle ^ pos ;) puisque pos, le casseur connaît). J'ai un peu de mal à imaginer qq ch d'intelligent sur ce coup, mais j'y reviendrai pê ce soir ...

Commentaire de bapt1080 le 29/03/2005 11:12:13

Pour ce qui est de la repetition, je suis tout a fait d'accord que moins ont repete la meme clef, moins c'est cassable mais j'ai fait cette source pour montrer un cryptage simple en xor a partir d'une clef aussi longue soit t'elle. Après il est sur que si tu rajoute un algo "secret" qui modifie l'ordre de la clef, ce sera pratiquement incassable tant qu'on ne connait pas l'algo (comme tout cryptage je dirais). La force d'un cryptage tiens dans le fait qu'il est impossible ou très difficile a crypter meme si on connait l'algo (comme rsa), d'ou l'utilisation de la factorisation des nombres premiers en crypto.
Si dans ce cas tu veux un cryptage solide, je te conseille de ne pas utiliser une clef pour crypter mais un fichier plus gros que le fichier que tu veux crypter.
La modif n'est pas dur a faire... tu passes le chemin du fichier au lieu de la clef et tu te deplace dans le fichier comme dans la clef, ce qui evite les repetitions de clef si ton fichier est plus gros que la source a crypter -> incassable.

Commentaire de TeLeTUbIz le 29/03/2005 14:25:40

moui, sauf que ca pose le problème du transport de la clé (qui sera aussi grosse que le fichier), et le problème principal reste: c'est l'humain qui est toujours ou presque à l'origine des dispersions de secret.

Bonne source.

Commentaire de Kirua le 29/03/2005 18:16:37

bapt, j'ai justement orienté mon message pour bien dire qu'il faut absolument que l'algo puisse être publié. c'est la condition sine qua non. un cryptage basé sur le caractère secret d'un algo, ça ne tient pas la route. donc ce que je suggérais, c'est de faire intervenir la position du caractère, mais de façon intelligente.

Commentaire de Penguin_X le 30/03/2005 00:34:28

Ça serait bien un décrypteur :)

Commentaire de Kirua le 30/03/2005 08:15:15

bah le xor est symétrique, c'est le même algo pr rypter et décrypter.

Commentaire de bapt1080 le 30/03/2005 09:55:49

merci kirua
et desolé, je navais pas compris ce que tu voulais exactement.

TeLeTUbIz : oui c vrai que pour les gros fichier ça pose probleme...

mais bon, à ce stade, si quelqu'un est inspiré pour nous montrez comment craquer un fichier crypter ainsi avec une clef entre 15 et 20 caracteres (> a 256 bits si je ne me trompe) on verrais deja qu'il faut du beaucoup de code et surtout ... du temps!!!

Commentaire de coucou747 le 30/03/2005 17:59:58

un cryptage basé sur le caractère secret d'un algo, ça ne tient pas la route. les allemands en ont fait les frais pendant la seconde guerre mondiale avec enigma...

pour kirua, je suposes que tu dois le savoir, mais ton message tend au kiproko...

un cryptage symétrique n'est pas un cryptage qui a le même algorythme pour crypter et décrypter, mais un cryptage qui utilises la même clef pour crypter et décrypter...

EX : pour DES et AES, pour crypter et décrypter, on fait les mêmes choses, mais pas dans le même ordre, donc les algos sont diférents, mais les clefs sont les mêmes, donc symétrique...

pour RSA, les clefs sont diférentes, mais l'algo est le même :
pour un couple de clefs (a,b) (RSA c'est deux clefs)
on a messagecode=message exposant a modulo de b...

que ce soit pour crypter ou pour décrypter...

car pour crypter, on utilises (d,n) et pour décrypter (e, n)

enfin, je suis hors sujet par raport à la source...



ce que tu peux faire pour modifier XOR :

pour une clef de 128 :
tu mets les huit premiers bits de coté, ils te donne un nombre entre 0 et 8 (si tu fais une adition, on peut inverser les bits, ça ne changer rien, alors que si tu les prends dans l'ordre, pour celui qui trouve la taille de la clef, c'est cassable), ça te donne combien de bits de clefs tu peux utiliser avant de prendre encore huit bits de clefs pour refaire la même chose... je n'ai fais aucun calculs sur le sujet, mais utiliser certaines parties de la clef comme ceci rendraient le cassage soit plus simple (eh oui, je ne suis pas expert en math... je peux me tromper (et me trompe souvent)... ) , soit réduit à un simple bruteforce (qui serait alors bcp plus long...)

Commentaire de Kirua le 30/03/2005 18:46:02

Oui, en effet coucou, merci pr la rectification tt à fait pertinente.

 Ajouter un commentaire




Nos sponsors


Sondage...

Comparez les prix

CalendriCode

Septembre 2010
LMMJVSD
  12345
6789101112
13141516171819
20212223242526
27282930   

Consulter la suite du CalendriCode

 
Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils.
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés

Google Coop CodeS-SourceS Google Coop CodeS-SourceS
Temps d'éxécution de la page : 0,343 sec (4)

Nous contacter | Annoncer sur CodeS-SourceS | Mentions légales