begin process at 2013 05 25 16:36:43
  Trouver un code source :
 
dans
 
Accueil > 

Code

 > 

Sécurité & Cryptage

 > NOUVEL ALGORITHME D'ENCRYPTION-DÉSENCRYPTION DYNAMIQUE (INFAILLIBLE)

NOUVEL ALGORITHME D'ENCRYPTION-DÉSENCRYPTION DYNAMIQUE (INFAILLIBLE)


 Information sur la source

Note :
1 / 10 - par 3 personnes
1,00 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10
Catégorie :Sécurité & Cryptage Source .NET ( DotNet ) Classé sous :encryption, cryptographie, sécurité, AES, RSA Niveau :Expert Date de création :14/11/2010 Vu / téléchargé :9 058 / 364

Auteur : vletktol

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

 Description

Voici un nouvel algoritme d'encryption / désencryption
qui est virtuellement incassable.

Celui-ci utilise un vecteur d'initialisation de 2048 bits. Donc cassable par brute-force uniquement.

Je n'encode pas par BLOCS.... donc impossible de déterminer la clef en analysant des parties du fichier encrypté.
Je simule un masque jetable.

Donc j'ai les avantages du masque jetable sans les inconvénients d'avoir une clef aussi longue que le fichier.


Voir P.J. Document word

Source

  • #include <windows.h>
  • //Fonctions Thread
  • DWORD WINAPI ThreadAC(LPVOID lpParam); //Thread qui s'occupe de vérifier l'état de l'interrupteur
  • class kaboomClass
  • {
  • private:
  • DWORD ThreadID; //Thread
  • HANDLE ThreadHandle;
  • unsigned char CLEFS[256]; //Clefs sous forme d'OCTET
  • bool CLEFS_B[256][8]; //Clefs sous forme de BITS
  • //Clef d'encryption actuelle
  • bool CLEF_ACTUELLE_B[8];
  • unsigned char CLEF_ACTUELLE;
  • unsigned char MIXKEY[8]; //indique les bits de quelle clefs à prendre (DÉPART)
  • int COMPTEUR_METHODE;
  • int METHODES[4]; //Indique l'ordre des méthodes a prendre (256 possibles sauf elles ne seront pas toutes prises)
  • public:
  • bool threadOK;
  • int pourcent;
  • kaboomClass();
  • ~kaboomClass();
  • void octetToBits(const unsigned char*, bool*);
  • void afficherBits(bool*);
  • unsigned char bitsToOctet(bool*);
  • void genererClefs();
  • void mixClef();
  • void nextMasq();
  • void afficherMasque();
  • void backupKeys();
  • void getKeys();
  • void ENCRYPTE();
  • void DECRYPTE();
  • void initialiser();
  • }*kaboom;
  • kaboomClass::kaboomClass()
  • {
  • pourcent=0;
  • threadOK=true;
  • //ThreadHandle=CreateThread(NULL,NULL,ThreadAC,NULL,NULL,&ThreadID);
  • }
  • kaboomClass::~kaboomClass()
  • {
  • threadOK=false;
  • TerminateThread(ThreadHandle,NULL);
  • }
  • //Extraire les 8 bits d'un octet
  • void kaboomClass::octetToBits(const unsigned char *octet, bool *bits) //OK FINAL
  • {
  • unsigned char a;
  • a=octet[0];
  • for (int x = 0; x <= 7; x++)
  • {
  • bits[x] = a & 1;
  • a = a >> 1;
  • }
  • return;
  • }
  • //Création d'un octet avec 8 bits
  • unsigned char kaboomClass::bitsToOctet(bool *bits) //OK FINAL
  • {
  • unsigned char byte=0;
  • for (int x = 0; x <= 7; x++)
  • {
  • if(bits[x])
  • byte+=pow((double)2,x);
  • }
  • return byte;
  • }
  • void kaboomClass::mixClef()
  • {
  • for(int x=0;x<=7;x++)
  • {
  • CLEF_ACTUELLE_B[x]=CLEFS_B[MIXKEY[x]][x];
  • }
  • CLEF_ACTUELLE=bitsToOctet(CLEF_ACTUELLE_B);
  • }
  • //Simulation d'une seule méthode pour le moment
  • void kaboomClass::nextMasq()
  • {
  • //Copy du masque de mélange actuel
  • unsigned char temp[8];
  • for(int x=0;x<=7;x++)
  • temp[x]=MIXKEY[x];
  • //Copy des méthodes
  • int temp2[4];
  • for(int x=0;x<=3;x++)
  • temp2[x]=METHODES[x];
  • switch(METHODES[COMPTEUR_METHODE])
  • {
  • case 1: //Méthode #1 = inversion totale
  • {
  • MIXKEY[0]=temp[4]+3;
  • MIXKEY[1]=temp[5]+1;
  • MIXKEY[2]=temp[0]+6;
  • MIXKEY[3]=temp[3]-4;
  • MIXKEY[4]=temp[1]+3;
  • MIXKEY[5]=temp[2];
  • MIXKEY[6]=temp[6]+2;
  • MIXKEY[7]=temp[7];
  • break;
  • }
  • case 25: //Méthode #25 : Inversion centrée
  • {
  • MIXKEY[0]=temp[2]-8;
  • MIXKEY[1]=temp[4]+2;
  • MIXKEY[2]=temp[3]+2;
  • MIXKEY[3]=temp[0]+43;
  • MIXKEY[4]=temp[1]-98;
  • MIXKEY[5]=temp[5]+54;
  • MIXKEY[6]=temp[6]+15;
  • MIXKEY[7]=temp[7]-32;
  • break;
  • }
  • case 52: //Méthode #52 : Changement de clefs
  • {
  • MIXKEY[0]=temp[0]+1;
  • MIXKEY[1]=temp[1]-2;
  • MIXKEY[2]=temp[2]-2;
  • MIXKEY[3]=temp[3]+16;
  • MIXKEY[4]=temp[4]+2;
  • MIXKEY[5]=temp[5]-1;
  • MIXKEY[6]=temp[6]+2;
  • MIXKEY[7]=temp[7]-4;
  • break;
  • }
  • case 55: //Méthode #55 : Inverser Méthodes ???
  • {
  • METHODES[0]=temp2[2];
  • METHODES[1]=temp2[3];
  • METHODES[2]=temp2[0];
  • METHODES[3]=temp2[2];
  • break;
  • }
  • default: //Méthode inconnue = inversion des paires
  • {
  • MIXKEY[0]=temp[5];
  • MIXKEY[1]=temp[0];
  • MIXKEY[2]=temp[4];
  • MIXKEY[3]=temp[1];
  • MIXKEY[4]=temp[2];
  • MIXKEY[5]=temp[3];
  • MIXKEY[6]=temp[6];
  • MIXKEY[7]=temp[7];
  • break;
  • }
  • }
  • COMPTEUR_METHODE++;
  • if(COMPTEUR_METHODE>3)
  • COMPTEUR_METHODE=0;
  • }
  • //###################################################################
  • //Générer des clefs de façon aléatoire
  • void kaboomClass::genererClefs() //OK
  • {
  • srand(time(NULL));
  • for(int x=0;x<=255;x++)
  • {
  • CLEFS[x]=rand() % 256;
  • octetToBits(&CLEFS[x],CLEFS_B[x]);
  • }
  • for(int x=0;x<=7;x++)
  • MIXKEY[x]=rand() % 256;
  • //****************
  • METHODES[0]=1;
  • METHODES[1]=25;
  • METHODES[2]=52;
  • METHODES[3]=55;
  • backupKeys();
  • return;
  • }
  • //Enregistrer les clefs
  • void kaboomClass::backupKeys()
  • {
  • char position[15]={"kabz.kbk"};
  • char *nomFichier=position;
  • ofstream fichier(nomFichier,ios::ate|ios::binary);
  • //Enregistre les 256 clefs
  • for(int x=0;x<=255;x++)
  • fichier.write((char*)&CLEFS[x],sizeof(CLEFS[x]));
  • //Enregistre le masque
  • for(int x=0;x<=7;x++)
  • fichier.write((char*)&MIXKEY[x],sizeof(MIXKEY[x]));
  • //Enregistre la séquence des méthodes
  • for(int x=0;x<=3;x++)
  • fichier.write((char*)&METHODES[x],sizeof(METHODES[x]));
  • fichier.close();
  • return;
  • }
  • //Récupérer les clefs
  • void kaboomClass::getKeys()
  • {
  • char position[15]={"kabz.kbk"};
  • char *nomFichier=position;
  • ifstream fichier(nomFichier,ios::binary);
  • //OBTENIR LONGUEUR FICHIER
  • fichier.seekg(0, ios::end);
  • double longFich=fichier.tellg();
  • fichier.seekg(0, ios::beg);
  • if((longFich>0))
  • {
  • //Récupère les 256 clefs
  • for(int x=0;x<=255;x++)
  • {
  • fichier.read((char*)&CLEFS[x],sizeof(CLEFS[x]));
  • octetToBits(&CLEFS[x],CLEFS_B[x]);
  • }
  • //Récupère le masque
  • for(int x=0;x<=7;x++)
  • fichier.read((char*)&MIXKEY[x],sizeof(MIXKEY[x]));
  • //Récupère la séquence des méthodes
  • for(int x=0;x<=3;x++)
  • fichier.read((char*)&METHODES[x],sizeof(METHODES[x]));
  • }
  • fichier.close();
  • return;
  • }
  • //###################################################################
  • void kaboomClass::ENCRYPTE()
  • {
  • pourcent=0;
  • COMPTEUR_METHODE=0;
  • genererClefs();
  • char position[15]={"test.mp3"};
  • char *nomFichier=position;
  • ifstream fichier(nomFichier,ios::binary);
  • char position2[15]={"crypted.kbm"};
  • char *nomFichier2=position2;
  • ofstream fichier2(nomFichier2,ios::binary|ios::ate);
  • char position3[15]={"masque.kbm"};
  • char *nomFichier3=position3;
  • ofstream fichier3(nomFichier3,ios::binary|ios::ate);
  • //OBTENIR LONGUEUR FICHIER
  • fichier.seekg(0, ios::end);
  • double longFich=fichier.tellg();
  • fichier.seekg(0, ios::beg);
  • unsigned char donnee;
  • if((longFich>0))
  • {
  • while(!fichier.eof())
  • {
  • mixClef();
  • fichier.read((char*)&donnee,sizeof(donnee));
  • donnee = donnee ^ CLEF_ACTUELLE;
  • //Écriture de la donnée encryptée
  • fichier2.write((char*)&donnee,sizeof(donnee));
  • //Écriture du masque jetable
  • fichier3.write((char*)&CLEF_ACTUELLE,sizeof(CLEF_ACTUELLE));
  • //pourcent = fichier.tellg() / longFich * 100;
  • nextMasq();
  • }
  • }
  • fichier.close();
  • fichier2.close();
  • fichier3.close();
  • return;
  • }
  • void kaboomClass::DECRYPTE()
  • {
  • pourcent=0;
  • COMPTEUR_METHODE=0;
  • getKeys();
  • char position[15]={"crypted.kbm"};
  • char *nomFichier=position;
  • ifstream fichier(nomFichier,ios::binary);
  • char position2[15]={"decrypted.mp3"};
  • char *nomFichier2=position2;
  • ofstream fichier2(nomFichier2,ios::binary|ios::ate);
  • //OBTENIR LONGUEUR FICHIER
  • fichier.seekg(0, ios::end);
  • double longFich=fichier.tellg();
  • fichier.seekg(0, ios::beg);
  • unsigned char donnee;
  • if((longFich>0))
  • {
  • while(!fichier.eof())
  • {
  • mixClef();
  • fichier.read((char*)&donnee,sizeof(donnee));
  • donnee = donnee ^ CLEF_ACTUELLE;
  • fichier2.write((char*)&donnee,sizeof(donnee));
  • //pourcent = fichier.tellg() / longFich * 100;
  • nextMasq();
  • }
  • }
  • fichier.close();
  • fichier2.close();
  • return;
  • }
  • DWORD WINAPI ThreadAC(LPVOID lpParam)
  • {
  • while(kaboom->threadOK) //Serveur tout le temps en fonction (à date)
  • {
  • system("cls");
  • cout << kaboom->pourcent << "%";
  • Sleep(100);
  • }
  • return 0;
  • }
#include <windows.h>

//Fonctions Thread
DWORD WINAPI ThreadAC(LPVOID lpParam); //Thread qui s'occupe de vérifier l'état de l'interrupteur

class kaboomClass
{
private:

	DWORD ThreadID; //Thread
	HANDLE ThreadHandle;
	

	unsigned char CLEFS[256]; //Clefs sous forme d'OCTET
	bool CLEFS_B[256][8]; //Clefs sous forme de BITS
	//Clef d'encryption actuelle
	bool CLEF_ACTUELLE_B[8]; 
	unsigned char CLEF_ACTUELLE;
	unsigned char MIXKEY[8]; //indique les bits de quelle clefs à prendre (DÉPART)
	int COMPTEUR_METHODE;
	int METHODES[4]; //Indique l'ordre des méthodes a prendre (256 possibles sauf elles ne seront pas toutes prises)


public:
	bool threadOK;
	int pourcent;

	kaboomClass();
	~kaboomClass();
	void octetToBits(const unsigned char*, bool*);
	void afficherBits(bool*);
	unsigned char bitsToOctet(bool*);
	void genererClefs();
	void mixClef();
	void nextMasq();
	void afficherMasque();
	void backupKeys();
	void getKeys();
	void ENCRYPTE();
	void DECRYPTE();
	void initialiser();

}*kaboom;


kaboomClass::kaboomClass()
{
	pourcent=0;
	threadOK=true;
	//ThreadHandle=CreateThread(NULL,NULL,ThreadAC,NULL,NULL,&ThreadID);
}


kaboomClass::~kaboomClass()
{
	threadOK=false;
	TerminateThread(ThreadHandle,NULL);
}



//Extraire les 8 bits d'un octet
void kaboomClass::octetToBits(const unsigned char *octet, bool *bits) //OK FINAL
{	
	unsigned char a;
	a=octet[0];
	for (int x = 0; x <= 7; x++)
	{
		bits[x] = a & 1;
		a = a >> 1; 
	}
	return;
}

//Création d'un octet avec 8 bits
unsigned char kaboomClass::bitsToOctet(bool *bits) //OK FINAL
{	
	unsigned char byte=0;
	for (int x = 0; x <= 7; x++)
	{
		if(bits[x])
			byte+=pow((double)2,x);
	}
	return byte;
}


void kaboomClass::mixClef()
{
	for(int x=0;x<=7;x++)
	{
		CLEF_ACTUELLE_B[x]=CLEFS_B[MIXKEY[x]][x];
	}
	CLEF_ACTUELLE=bitsToOctet(CLEF_ACTUELLE_B);
}

//Simulation d'une seule méthode pour le moment
void kaboomClass::nextMasq()
{
	//Copy du masque de mélange actuel
	unsigned char temp[8];
	for(int x=0;x<=7;x++)
		temp[x]=MIXKEY[x];

	//Copy des méthodes
	int temp2[4];
	for(int x=0;x<=3;x++)
		temp2[x]=METHODES[x];

	switch(METHODES[COMPTEUR_METHODE])
	{
		case 1: //Méthode #1 = inversion totale
		{
			MIXKEY[0]=temp[4]+3;
			MIXKEY[1]=temp[5]+1;
			MIXKEY[2]=temp[0]+6;
			MIXKEY[3]=temp[3]-4;
			MIXKEY[4]=temp[1]+3;
			MIXKEY[5]=temp[2];
			MIXKEY[6]=temp[6]+2;
			MIXKEY[7]=temp[7];
			break;
		}
		case 25: //Méthode #25 : Inversion centrée
		{
			MIXKEY[0]=temp[2]-8;
			MIXKEY[1]=temp[4]+2;
			MIXKEY[2]=temp[3]+2;
			MIXKEY[3]=temp[0]+43;
			MIXKEY[4]=temp[1]-98;
			MIXKEY[5]=temp[5]+54;
			MIXKEY[6]=temp[6]+15;
			MIXKEY[7]=temp[7]-32;
			break;
		}
		case 52: //Méthode #52 : Changement de clefs
		{
			MIXKEY[0]=temp[0]+1;
			MIXKEY[1]=temp[1]-2;
			MIXKEY[2]=temp[2]-2;
			MIXKEY[3]=temp[3]+16;
			MIXKEY[4]=temp[4]+2;
			MIXKEY[5]=temp[5]-1;
			MIXKEY[6]=temp[6]+2;
			MIXKEY[7]=temp[7]-4;
			break;
		}
		case 55: //Méthode #55 : Inverser Méthodes ???
		{
			METHODES[0]=temp2[2];
			METHODES[1]=temp2[3];
			METHODES[2]=temp2[0];
			METHODES[3]=temp2[2];
			break;
		}
		default: //Méthode inconnue = inversion des paires
		{
			MIXKEY[0]=temp[5];
			MIXKEY[1]=temp[0];
			MIXKEY[2]=temp[4];
			MIXKEY[3]=temp[1];
			MIXKEY[4]=temp[2];
			MIXKEY[5]=temp[3];
			MIXKEY[6]=temp[6];
			MIXKEY[7]=temp[7];
			break;
		}
	}

	COMPTEUR_METHODE++;
	if(COMPTEUR_METHODE>3)
		COMPTEUR_METHODE=0;
}
//###################################################################

//Générer des clefs de façon aléatoire
void kaboomClass::genererClefs() //OK
{	
	srand(time(NULL));
	for(int x=0;x<=255;x++)
	{
		CLEFS[x]=rand() % 256;
		octetToBits(&CLEFS[x],CLEFS_B[x]);
	}

	for(int x=0;x<=7;x++)
		MIXKEY[x]=rand() % 256; 
	
	//****************
	METHODES[0]=1;
	METHODES[1]=25;
	METHODES[2]=52;
	METHODES[3]=55;

	backupKeys();
	return;
}


//Enregistrer les clefs
void kaboomClass::backupKeys() 
{	
	char position[15]={"kabz.kbk"};
	char *nomFichier=position;

	ofstream fichier(nomFichier,ios::ate|ios::binary); 

	//Enregistre les 256 clefs
	for(int x=0;x<=255;x++)
		fichier.write((char*)&CLEFS[x],sizeof(CLEFS[x])); 
	//Enregistre le masque
	for(int x=0;x<=7;x++)
		fichier.write((char*)&MIXKEY[x],sizeof(MIXKEY[x])); 
	//Enregistre la séquence des méthodes
	for(int x=0;x<=3;x++)
		fichier.write((char*)&METHODES[x],sizeof(METHODES[x])); 
	fichier.close();
	return;
}

//Récupérer les clefs
void kaboomClass::getKeys() 
{	
	char position[15]={"kabz.kbk"};
	char *nomFichier=position;

	ifstream fichier(nomFichier,ios::binary); 

	//OBTENIR LONGUEUR FICHIER
	fichier.seekg(0, ios::end);
	double longFich=fichier.tellg();
	fichier.seekg(0, ios::beg);

	if((longFich>0))
	{
		//Récupère les 256 clefs
		for(int x=0;x<=255;x++)
		{
			fichier.read((char*)&CLEFS[x],sizeof(CLEFS[x]));
			octetToBits(&CLEFS[x],CLEFS_B[x]); 
		}
		//Récupère le masque
		for(int x=0;x<=7;x++)
			fichier.read((char*)&MIXKEY[x],sizeof(MIXKEY[x]));
		//Récupère la séquence des méthodes
		for(int x=0;x<=3;x++)
			fichier.read((char*)&METHODES[x],sizeof(METHODES[x])); 
	}
	fichier.close();
	return;
}

//###################################################################

void kaboomClass::ENCRYPTE() 
{	
	pourcent=0;
	COMPTEUR_METHODE=0;
	genererClefs();

	char position[15]={"test.mp3"};
	char *nomFichier=position;
	ifstream fichier(nomFichier,ios::binary); 

	char position2[15]={"crypted.kbm"};
	char *nomFichier2=position2;
	ofstream fichier2(nomFichier2,ios::binary|ios::ate); 

	char position3[15]={"masque.kbm"};
	char *nomFichier3=position3;
	ofstream fichier3(nomFichier3,ios::binary|ios::ate); 

	//OBTENIR LONGUEUR FICHIER
	fichier.seekg(0, ios::end);
	double longFich=fichier.tellg();
	fichier.seekg(0, ios::beg);

	unsigned char donnee;

	if((longFich>0))
	{
		while(!fichier.eof())
		{
			mixClef();
			fichier.read((char*)&donnee,sizeof(donnee));

			donnee = donnee ^ CLEF_ACTUELLE;
			//Écriture de la donnée encryptée
			fichier2.write((char*)&donnee,sizeof(donnee));
			//Écriture du masque jetable
			fichier3.write((char*)&CLEF_ACTUELLE,sizeof(CLEF_ACTUELLE));

			//pourcent = fichier.tellg() / longFich * 100;

			nextMasq();
		}
	}
	fichier.close();
	fichier2.close();
	fichier3.close();
	return;
}


void kaboomClass::DECRYPTE() 
{	
	pourcent=0;
	COMPTEUR_METHODE=0;
	getKeys();

	char position[15]={"crypted.kbm"};
	char *nomFichier=position;
	ifstream fichier(nomFichier,ios::binary); 

	char position2[15]={"decrypted.mp3"};
	char *nomFichier2=position2;
	ofstream fichier2(nomFichier2,ios::binary|ios::ate); 

	//OBTENIR LONGUEUR FICHIER
	fichier.seekg(0, ios::end);
	double longFich=fichier.tellg();
	fichier.seekg(0, ios::beg);

	unsigned char donnee;

	if((longFich>0))
	{
		while(!fichier.eof())
		{
			mixClef();
			fichier.read((char*)&donnee,sizeof(donnee));

			donnee = donnee ^ CLEF_ACTUELLE;

			fichier2.write((char*)&donnee,sizeof(donnee));

			//pourcent = fichier.tellg() / longFich * 100;

			nextMasq();
		}
	}
	fichier.close();
	fichier2.close();
	return;
}

DWORD WINAPI ThreadAC(LPVOID lpParam)
{
	while(kaboom->threadOK) //Serveur tout le temps en fonction (à date)
	{
		system("cls"); 
	    cout << kaboom->pourcent << "%";
		Sleep(100);
	}
	return 0;
}

 Conclusion

Veuillez lire le tutoriel .DOC que j'ai inclu dans le ZIP.

Sérieusement, je ne sais pas si j'ai inventé de quoi ou bien je suis dans les patates.

En tout cas; je SAIS QUE CELA FONCTIONNE #1.

J'Ai encrypté un fichier de 1 meg avec seulement des "00" dedant et le fichier crypté est méconnaissable !!

Bonne découverte... !

 Fichier Zip

Les Membres Club peuvent télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

Télécharger le zip


 Sources de la même categorie

Source avec Zip STÉGANOGRAPHIE BITMAP par litdouilletdu85
PROJET DE CRYPTOGRAPHIE: RSA À JEU REDUIT D'INSTRUCTION par samatarahmed
Source avec Zip Source avec une capture CRYPTOSYSTÈME ELGAMAL LIBRAIRIE GMP par louelh95
Source avec Zip A2DCRYPT - CRYPTAGE 2048 BITS par darkor
Source avec Zip Source avec une capture CRYPTEUR-DÉCRYPTEUR-IP par antho974

 Sources en rapport avec celle ci

Source avec Zip Source avec une capture SECURE REMOTE SHELL [WIN32] par ganjarasta
PROJET DE CRYPTOGRAPHIE: RSA À JEU REDUIT D'INSTRUCTION par samatarahmed
Source avec Zip Source avec une capture CRYPTOSYSTÈME ELGAMAL LIBRAIRIE GMP par louelh95
Source avec Zip Source avec une capture SECUREVAULT : APPLICATION POUR CRYPTER VOS FICHIERS AVEC AES... par steelbox
Source avec une capture CODAGE RSA SUR 1024 BITS par jourgun

Commentaires et avis

Commentaire de vletktol le 14/11/2010 16:18:13

-Veuillez prendre note que certaines variables et commentaires de ce code source sont incohérents.... J'ai copié du code de mes anciens code source pour sauver du temps :)

-Normalement en compilant la source; il faut avoir un fichier "test.mp3" dans le meme dossier que l'exécutable. Le logiciel va l'encrypter et créer 3 fichiers.....
crypted.kbm --> Fichier encrypté (même taille que le fichier non encrypté)

masque.kbm --> Fichier qui contient le masque jetable.... Il est de la taille du fichier encrypté... Ce n'est pas utile d'avoir une clef aussi longue que le fichier lui-même. Mais il est possibe de décrypter le fichier avec celui-ci aussi. Il est plus avantageux d'utiliser "kabz.kbk" pour décrypter le fichier. "MASQUE.KBM" est inutile et a été généré seulement pour démonstration et tests....


kabz.kbk --> Fichier qui contient la bibliothèque, le filtre binaire et le séquenceur.... (Vecteur d'initialisation interrelié en 3 parties)

decrypted.mp3 --> Fichier décrypté à l'aide de "kabz.kbk"


J'Attends vos commentaires :P

Commentaire de X_Cli le 15/11/2010 10:24:53

Bonjour,
Je n'ai pas étudié le code source, mais rien que le titre me fait tiquer :
NOUVEL ALGORITHME D'ENCRYPTION-DÉSENCRYPTION DYNAMIQUE (INFAILLIBLE)

Nouvel : un algorithme a besoin d'être prouvé mathématiquement comme étant un problème difficile à résoudre. De plus, AES peine encore à s'imposer face à DES, alors il est assez improbable qu'un nouvel algorithme puisse être conseillé d'être utilisé aujourd'hui.
Encryption-Désencryption : cela dénote un manque de culture générale dans le domaine de la cryptographie, puisque les termes adéquats en francais sont chiffrement et déchiffrement. Je ne dis pas que vous n'êtes pas expert dans le domaine, ca je n'en sais rien, mais que l'usage des mots standards me met la puce à l'oreille.
Infaillible : un algorithme de chiffrement peut être prouvé mathématiquement comme difficile à résoudre, pour le moment. Ca ne signifie pas qu'il ne le sera pas un jour. Ce qui est réputé difficile aujourd'hui ne le sera plus dans 10 ans. Infaillible dénote une absence de compréhension totale du fonctionnement de la cryptographie. De plus, même si un algo est mathématiquement difficile à résoudre, cela ne signifie en rien que son implémentation ne soit pas faillible, et c'est pourtant très souvent le cas (cf. openssl et debian par exemple).

Pour finir, l'utilisation de rand comme source de bits aléatoires me semble bien insuffisant, car l'entropie est trop faible. Je vous conseille de regarder autour des algorithmes de génération de bits aléatoires qui sont bien plus efficaces.

Commentaire de CptPingu le 15/11/2010 11:23:56 administrateur CS

@X_Cli: Réponse parfaite, on n'aurait pas pu faire mieux.

J'ajouterais juste: En quoi est-ce un code .Net ?

Commentaire de X_Cli le 15/11/2010 12:30:56

@CPTPingu : Merci du compliment :)

@vletktol : Si vous lisez l'anglais, je vous recommande deux livres qui vous permettront d'avoir du recul sur votre code ; ces deux livres sont de Bruce Schneier, qui fait autorité dans le domaine : "Applied Cryptography" et "Secrets and Lies".

Commentaire de vletktol le 15/11/2010 12:38:25

Avant de poster un commentaire inutile; Veuillez au moins avoir essayé l'algoritme. Des paroles en l'air et de la réticence au changement ce n'est pas bienvenue ici. Il faut faire place à une ouverture d'esprit et accepter qu'il y aura mieux que AES et DES.......


ESSAYEZ et CRITIQUEZ après....

Commentaire de X_Cli le 15/11/2010 12:45:14 1/10

J'aurais envie de dire que nos commentaires ont été inutiles, et je vous rejoins sur ce point, mais non pas parce que nous n'avons pas exécuté le code, mais parce que vous êtes aveuglé par une arrogance bien mal placée.
Vous parlez d'ouverture d'esprit ? Prenez le recul nécessaire pour juger votre travail en lisant les deux oeuvres que j'ai recommandé, et vous comprendrez de quoi il retourne.

Commentaire de vletktol le 15/11/2010 12:48:33

Mon algoritme n'est pas un problème mathématique compliqué à résoudre. Il est basé sur le principe d'un MASQUE JETABLE.
L'algorithme théoriquement parfait.

1 chance sur 256 à chaque octet de trouver la bonne clef.
Plus le fichier est grand; plus les chances sont minces à le décrypter.

J'aimerais bien que vous lisiez le tutoriel en format .DOC que j'ai mis dans le fichier zip avec le code source.

Commentaire de CptPingu le 15/11/2010 12:49:53 administrateur CS 1/10

Tu dois toi même faire preuve d'ouverture d'esprit et te rendre compte que les remarques de X_CLI sont parfaitements adaptés.
Il y aura sous doute mieux que AES et DES (relire le post de X_CLI), mais ça ne sera sûrement pas ta source.

Rien que dans ta source, il y a déjà des lourdeurs de code:
- "return" en fin de fonction inutile lorsqu'il y a un type void en sortie
- using namespace std, à proscrire.
- Instanciation d'objet inutile (pas besoin de new-delete dans le main, juste l'objet en local)
- Code dans le .h
- Utilisation de system

Joins à ça des termes mal employé, la crédibilité est au plus bas.

Commentaire de vletktol le 15/11/2010 12:54:25

Veuillez lire le .DOC et apprenez le PRINCIPE LOGIQUE de l'algorithme et arrêtez de critiquer le code source. CELUI-CI a été codé RAPIDEMENT et n'est nullement OPTIMISé.

"Monsieur j'ai écrit 2 livres donc j'ai raison et écoute moi.... AHAHAHAH"

Commentaire de X_Cli le 15/11/2010 13:14:49

Je m'arreterai par ce dernier commentaire : l'usage de one time pad (ou masque jetable) existe depuis la nuit des temps. Pour donner un exemple, le one time pad permet d'éviter les attaques statistiques sur l'algorithme de Vigenère (16ième siècle) (et ce n'est clairement pas le plus ancien).
Pourtant, dans le monde de la cryptographie, leur usage est quasi inexistant : pourquoi ?
Parce qu'il est aussi couteux de transporter de manière sécuriser le masque que de transporter le message lui même. Si le masque est intercepté, le message a beau être chiffré, il sera déchiffré, et si le masque n'est pas intercepté, alors nous aurions aussi bien fait d'envoyer par cette méthode directement le message en clair.
C'est justement tout l'intêret des algo comme DES et consort : la taille de la clé n'a pas besoin d'être bcp plus longue de 128 bits. C'est d'ailleurs sur des clé 128 bits, (parfois 256 bits) que reposent toutes les transactions bancaires actuelles sur internet, et pas sur des one time pad.

Commentaire de vletktol le 15/11/2010 13:20:10

J'en revient pas.... Êtes-vous bouchés ou quoi ???

Mon code source utilise un masque jetable et possède la qualité d'avoir un vecteur d'initilisation de 2048 bits pour déchiffer tout le fichier.

pas besoin d'une clef de la longueur du fichier.....

De plus mon algorithme n'est pas conçu actuellement pour fonctionner en mode client-serveur sur internet..... Il est conçu pour crypter des FICHIERS....

Commentaire de CptPingu le 15/11/2010 13:58:52 administrateur CS

Non, je n'en reviens pas que tu sois aussi borné.
PS: crypter => chiffrer

Commentaire de era le 15/11/2010 15:41:34

ne vous enervez pas
il est vrai que ce que nous avons la n est pas un algorithme mais un programme.
Un algo(algorithme) est une ecriture litterale d'un programme ce qui lui permet d'etre traduis d'en n importe quel langage de programmation

BON COURAGE
et merci d'ecrire l algo pour mieux le comprendre je ne fais pas de C et j aimerai le faire en java.

Commentaire de vletktol le 15/11/2010 18:26:30

Pour le moment je n'ai pas le temps de réécrire ce logiciel en JAVA. Malgré que cela serait facile.
JE vous conseille donc d'aller voir la pièce jointe. Vous y trouverai un document WORD qui vous explique la procédure
en détail. (un genre d'algorithme très rudimentaire :P)

Commentaire de iguypouf le 22/11/2010 10:01:00

VLEKTOL, je ne comprends pas l'approche que tu donnes à ton propre code.

1/ "J'ai testé avec un fichier de 3 mégas". Crois-tu qu'un test suffise ? L'exception qui fait la règle ? T'es-tu juste penché sur la possibilité qu'une des combinaisons puisse résulter en un chiffrement indéchiffrable ensuite (la base de l'analyse de tout chiffrement réversible).

2/ X_CLI essaye de t'expliquer un principe de base : puisque ton masque est jetable, il est appelé à être renouvelé / différent à chaque chiffrement. Et donc : ce masque va lui aussi devoir être transporté avec le fichier crypté, sous peine de ne pouvoir le déchiffrer ensuite. Donc, la sécurité "relative" de ton chiffrement dépend uniquement de la sécurité avec laquelle tu vas transporter ton masque; si tu as une sécurité INFAILLIBLE pour transporter ton masque, alors ne t'emmerde pas : transporte directement ton fichier en clair via ce canal, puisqu'il est INFAILLIBLE.


Je comprends que tu sois enthousiaste, mais un bon procédé de chiffrement, validé, réputé, ne peut être approché "au-pti-bonheur-la-chance", et testé avec un aussi petit panel d'échantillons.

Commentaire de LeFauve42 le 22/11/2010 11:36:53

+1 pour les divers commentaires...
Il s'agit d'une reprise du "one time pad" sauf que ca n'utilise qu'une cle de 2048 bits... ce qui enleve donc l'unique interet du one time pad (ou masque jetable).
En effet, meme si tu generes une cle plus longue en utilisant un algo (aussi tordu soit-il), vu que l'algo est connu, c'est comme si tu n'avais qu'une cle de 2048 bits.
Et donc, les classiques attaques a base de statistiques vont fonctionner.
Une petite remarque: si en plus tu veux crypter des fichiers (et non de l'information brute), il y a des mesures supplementaires a prendre, comme ne surtout pas crypter l'entete du fichier (celui-ci est facilement deductible, ce qui va compromettre une bonne partie de ta cle).
Si "Applied Cryptography" est bien le livre dont je me souviens, il commencait par une phrase du genre "Il existe 2 sortes de cryptographie : Celle destinee a empecher votre petite soeur d'acceder a vos donnees et celle destinee a empecher les dirigeants des grandes puissances de ce monde a acceder a vos donnees. Ce livre parle de la seconde".
Ce code source appartient par contre a la premiere :o).
VLETKTOL: Plutot que de raler contre ces commentaires tres pertinents, tu devrais lire un de ces bouquins (ou selon ton niveau de math, un de ces bouquins expliquant la crypto qu'on trouve chez nature et decouvertes (serieusement, c'est une bonne base au moins pour comprendre les trucs a ne pas faire :o) )).
Et puis le but de ce genre de site est de poster des codes utiles aux gens, alors plutot que de mettre des remarques genre "Veuillez prendre note que certaines variables et commentaires de ce code source sont incohérents.... J'ai copié du code de mes anciens code source pour sauver du temps :)", prend une dizaine de minutes pour mettre des commentaires pertinents. C'est plus correct pour les gens qui vont donner leur temps pour lire ton code, et en plus ca te sera utile quand tu voudras modifier ton code.

Commentaire de dcpi le 22/11/2010 22:37:21

Il y a quand même des gens assez méchants sur ce forum^^. Vlektol a exagéré en parlant d'algorithme infaillible (aucun algorithme de chiffrement/déchiffrement ne l'est). Encore moins un algorithme où il y a besoin de transmettre une donnée à chaque message (clé privée en quelque sorte. Un algorithme doit de plus être prouvé formellement (voir la logique de Hoare). Mais franchement, cppfrance est aussi un site destiné à l'apprentissage. Et vous me citerez beaucoup de gens capables de casser un code, même simple (la plupart des gens s'arrêtent au code de césar). Le but n'est pas ici de chiffrer des données concernant des bases de missiles ultra-secrètes à ce que je sache (pour cela, je pense qu'ils doivent utiliser des courbes elliptiques ou quelque chose de bien plus coriace).
Encryption est le mot englais, et tout bon informaticien programme en anglais, même le meilleur cryptanalyste(mais si). (même si ce site est français)

Désolé d'avoir perturbé cette petite "dispute", je m'en vais. Salut

Commentaire de jmorisseau le 23/11/2010 10:54:05

Il est vrai qu'on est méchant. Mais il a mis infaillible alors que le cryptage se fait avec un XOR. Et nouveau alors que ce système date de 1917 (cf chiffre de Vernam) et j'ai souvenir avoir fait un logiciel utilisant cet algorithme en pascal 7.

Commentaire de Lzappeur le 23/11/2010 11:55:29

Bonjour à tous,
Je ne comprends pas grand chose à la cryptographie mais cela ne m'intéresse pas moins pour autant.
Mais j'aimerais savoir: Est il possible de déchiffrer un fichier si tout le programme de chifrement
est mise en clair sur le Net ?
C'est peut être une question bête !!!

Lzappeur...

Merci à tous pour ces commentaires éclairés.

Commentaire de X_Cli le 23/11/2010 12:09:51

LZappeur : Non, un algorithme est même "meilleur" en étant public (puisque sa résistance peut être testée par n'importe qui, plutôt que de se reposer sur le seul secret de l'algorithme).

C'est le même principe qui fait qu'un logiciel libre tendra à être plus sécurisé qu'un logiciel privateur.

Ce principe, en crypto, s'appelle le Principe de Kerckhoffs.

http://fr.wikipedia.org/wiki/Principe_de_Kerckhoffs

Commentaire de LeFauve42 le 23/11/2010 13:47:30

> Vlektol a exagéré en parlant d'algorithme infaillible (aucun algorithme de chiffrement/déchiffrement ne l'est)

En fait, si par "infaillible" tu entends qu'il n'est pas possible de dechiffrer le message sans connaitre la cle de chiffrement, il se trouve que le "one time pad" ou "masque jetable" l'est :o).
Ce chiffrement a cependant d'autres inconvenients, comme le besoin de partager une cle aussi longue que le message.
J'ajouterais cependant une remarque a ce que j'ai lu dans certains commentaires du style "Si tu peux transferer la cle de maniere sure, tu peux transferer directement le message (qui fait la meme taille)".
Ce n'est pas tout a fait vrai :
- D'abord, on n'est pas oblige de transferer la cle. On peut tres bien imaginer que les deux parties desirant correspondre de maniere securisee se rencontrent en personne et s'echangent une longue cle securisee (identique). Par exemple, un DVD grave avec des octets aleatoires. Il leur suffit ensuite de s'envoyer des messages cryptes en one-time-pad avec cette cle, plus l'offset de debut de la cle (pour ne jamais reutiliser plusieurs fois la meme partie de la cle qui deviendrait alors vulnerable aux attaques statistiques). Durant la seconde guerre mondiale, les espions utilisaient des livres. Par exemple l'espion A utilisait "Les 3 mousquetaires", et quand il donnait comme offset 5623 le recepteur savait qu'il fallait utiliser comme cle les lettres du livre a partir du 23eme mot de la page 56 (de la meme edition bien sur :o) )
- On peut aussi transferer la cle d'abord, et n'envoyer le message qu'une fois qu'on n'est sur que la cle n'a pas ete interceptee (ce n'est pas toujours possible, mais sur un reseau quantique par exemple, ca l'est).
- Une autre option est d'utiliser plusieurs canaux differents pour la cle et le message (un peu comme les premiers sites de payement internet ou on pouvait envoyer le debut de son numero de CB par internet et la fin par telephone). Par exemple, si vous ne voulez pas que votre operateur mail lise vos message, vous pourriez utiliser 2 adresses (chez des operateurs differents), et envoyer la cle sur une, et le message sur l'autre (un peu comme Nike qui fait fabrique ses chaussures gauches et droites dans des pays differents pour eviter que le personnel local ne puisse sortir des paires en douce... mais je m'eloigne du sujet :o) ).

Bref, pour simplifier, ce programme propose une methode pour "allonger" une cle de 2048 bits afin d'utiliser le one-time-pad. C'est cette methode d'allongement qui compromet l'infaillibilite du one-time-pad, qui a part ca est un bon algo qui a fait ses preuves dans des cas reels.

Commentaire de X_Cli le 23/11/2010 17:30:22

@LeFauve42 : en effet, très bonne réponse. Je te concède tous les points évoqués et où mes affirmations, notamment, étaient passablement fausses ou incomplètes. :)

Commentaire de vletktol le 23/11/2010 18:20:19

EN EFFET, J'ALLONGE UNE CLEF DE 2048 BITS.

SAUF QUE CETTE CLEF ELLE-MÊME A UNE RELATION AVEC ELLE-MÊME ET JE N'UTILISE PAS LES OCTETS DU FICHIER À CHIFFRER POUR MODIFIER CETTE CLEF. CONTRAIREMENT AUX AUTRES ALGORITHMES DE CHIFFREMENT.

LA CLEF SE MODIFIE PAR ELLE-MÊME SELON 3 VARIABLES.
LE COMPTEUR, LA LONGUEUR DU COMPTEUR, LES FONCTIONS, ETC....

Commentaire de vletktol le 23/11/2010 18:32:54

Quand une clef n'a pas de relation de chiffrement avec les données brutes à chiffrer; (Autre que le XOR)
Alors nous pouvons dire que tout le fichier repose sur 2048 bits.

Nous ne pouvons pas établir de lien ou de relation sur les données du fichier chiffré.

Donc le seul moyen de déchiffrer est d'essayer 2^2048 possibilités (2048 bits).

DE LÀ VIENT LE MOT INFAILLIBLE (ONE TIME PAD)

-Simulation de ONE TIME PAD sans avoir besoin de la clef aussi grosse que le fichier pour le déchiffrer. JE ne chiffre pas par bloc de fichier. Donc à chaque 2048 bits; ce ne sera pas la même clef temporaire de chiffrement. (comme TKIP)

-Je le répète: Vu que je n'établie AUCUNE RELATION entre la clef et le fichier à chiffrer; alors nous ne pouvons pas établir de LIEN par attaque par statistique.
ET Vu que je ne chiffre pas par bloc de 2048 bits; Nous ne pouvons pas COMPARER chaque bloc entre eux.

MERCI ET BONNE JOURNÉE

Commentaire de CptPingu le 23/11/2010 18:46:41 administrateur CS

http://www.352media.com/rantingandraving/CMFiles/Images/CapsLock.jpg

Commentaire de X_Cli le 23/11/2010 21:01:51

Sans être, et de loin, expert en cryptographie, si on réutilise des bits de la clé 2048 plusieurs fois, a fortiori avec un algorithme connu, on abaisse l'entropie de la clé qui passe de 2048 bits à qqch de moins que 2048 (je laisse ca aux mathématiciens :p) et de ce fait, on affaiblit la clé.

Commentaire de LeFauve42 le 24/11/2010 11:50:40

Bonjour,

@X_CLI: Merci, mais tes commentaires etaient tres pertinents aussi :o)

@VLETKTOL:
> Donc le seul moyen de déchiffrer est d'essayer 2^2048 possibilités (2048 bits).
> DE LÀ VIENT LE MOT INFAILLIBLE (ONE TIME PAD)

Hum.. comment dire ca de maniere un peu diplomatique... Non !
La taille de la clé n'a rien a voir avec l'infaillibilite.
Attaquer en force brute une cle de 2048 bits, c'est pas impossible, c'est juste tres long.

Le one-time-pad, par contre, c'est impossible a dechiffrer.

2048 bits peuvent te parraitre incassable parce qu'avec les CPUs actuels, il faudrait 10, 100 ou meme 1000 ans pour tester toutes les possibilites, mais un jour ca se cassera en moins d'une minute avec un smartphone d'entree de gamme :o)

Le one-time-pad par contre, meme si tu avais un ordinateur "magique" capable de tester instantanement toutes les combinaisons, ca reste incassable. Je veux dire par la que si tu attaques en force brute, tu vas bien trouver le message envoye, mais aussi tous les autres messages possibles de la meme taille, et tu n'auras aucun moyen de savoir lequel etait le bon.

> ET Vu que je ne chiffre pas par bloc de 2048 bits; Nous ne pouvons pas COMPARER chaque bloc entre eux.

Dans le cas du carre de Vigenère (c'est qu'est le one-time-pad, si on lui enleve sa cle non reutilisable), la comparaison des blocks entre eux est surtout utilisee pour trouver la taille de la cle.
Dans ton algo, on la connait :o)

Je vais essayer de reformuler ce que j'ai dit :
Oui, les methodes classiques d'attaque d'un chiffrement a la Vigenère ne vont pas fonctionner "out of the box" sur les messages chiffres avec ton programme, mais une simple adaptation prenant en compte tes modifications rend ton chiffrement aussi vulnerable que si ta cle ne faisait que 2048 bits.
Alors oui, 2048 bits c'est long a casser, mais pas impossible.

Sinon pour parler du code, voici quelques autres remarques :
- Il y a des moyens plus efficaces de transformer des octets en bits et vice versa, mais surtout : Est-ce que tu as vraiment besoin de transformer tes octets en bits pour realiser ton chiffrement ?
- Essaie d'etre consistant dans tes nommages de fonction ou variables. Certaines sont en majuscules, ce qui n'aide pas vraiment a la relecture (les vieux de la vielle vont essayer de trouver ou tu as planque tes "#define" :o) ).
- Tu n'as sans doute pas besoin d'utiliser un thread pour afficher la progression de ton chiffrement.
- Si tu veux vraiment faire du multithread, tu pourrais par exemple faire faire tes tranches de 2048 bits a des threads differents afin de paralleliser.
- Plutot que de faire un system("cls") pour effacer l'ecran, tu devrais regarder vers les sequences ANSI. Ce serait bien plus rapide (surtout sur un monocore).
- D'ailleur, un simple cout << '\r' devrait remettre le curseur en debut de ligne, donc tu pourrais juste afficher ton avencement sans avoir a effacer l'ecran.

Commentaire de jornov7 le 25/11/2010 11:13:05

A vletktol:

Voilà, c'est aussi de la même façon que des génies sont mort avec leurs trouvailles dans l'ombre. Je dis cela par rapport au principe.
Ceux qui ont un Nom et ceux qui les défendent se mettront toujours en ordre de bataille contre un petit David qui croit que sa fronde est efficace au grand rire moqueur du Goliath.
Alors rassurez-vous, ne vous découragez pas car peut être qu'un jour une personne bien optimisera votre travail pour le rendre vraiment infaillible.

Ce qui fait avancer les choses c'est la complémentarité des collaborateurs pour obtenir un résultat probant et non pas la rivalité de parti orgueilleuse et jalouse.

Bon courage!

Commentaire de CptPingu le 25/11/2010 11:29:04 administrateur CS

@jornov7: Le gars qui a rien compris... Je doute fortement que tu ais des connaissances dans ce domaine. En informatique, il n'y a pas ce genre de rivalité dont tu parles. Si un programme est révolutionnaire, il est immédiatemment connu et reconnu (suffit de voir sur github la qualité de ce qui est partagé). L'auteur a beau clamer avec arrogance que son programme est la prochaine avancé scientifique du siècle, son programme n'est pas la hauteur de sa prétention, tout simplement.

Commentaire de iguypouf le 25/11/2010 11:42:17

Mais ce qu'on appelle "rivalité de parti", ce n'est rien d'autre que des conseil d'optimisation de travail vu par les yeux d'un "critiqué" non ouvert à la critique.

N'oubliez pas, Jornov, que l'auteur lui-même conclut son post par "j'attends vos commentaires", alors qu'il est très peu enclin à les entendre...

Concernant la puissance nécessaire pour craquer en brute force des clés, il y a un justement un nouvel article très intéressant concernant cela : l'utilisation du cloud computing à ce genre de fins. Ou comment avoir, grâce au cloud, la puissance de 200 ordinateurs dans ton petit dual core tout ce qu'il y a de plus classique...

Commentaire de vletktol le 26/11/2010 02:17:18

C'est bien beau pouvoir tester toutes les possibilités de 2048bits. Il s'agit de re-créer des octets à partir de rien. Nous ne pouvons pas nous baser sur rien pour savoir si nous sommes dans le bon chemin pour déchiffrer le message.

De là vient le mot infaillible,


Une chose est sûre à 100%. One Time Pad c'Est la chose la plus puissante qui existe sur terre.

Essayons de créer quelque chose qui s'en rapproche le plus.


La perfection n'est pas sur cette terre. Mais nous pouvons s'en rapprocher.

Commentaire de X_Cli le 26/11/2010 07:15:05

Le simple fait de réutiliser des morceaux de ta clé pour la rallonger artificiellement fait que tu affaiblis ta clé... je l'ai déjà dit, et je pourrais le redire jusqu'à ce que ce soit compris : ton système ne "fonctionne" que dans le cas d'un clair inconnu. Dans le cas d'un clair semi-connu, ta clé devient faible, car obtenir une portion de la clé sur le clair connu permettra de décrypter (et pas déchiffrer, amis du vocabulaire) d'autres parties du message. Cela n'arrive pas avec des algorithme CBC qui réutilise le résultat du bloc précédent pour chiffrer le bloc suivant.

Commentaire de attreid le 29/11/2010 14:16:33

vletktol, que se passe-t-il si, lorsque tu envoies ton fichier et la clef pour le déchiffrer, quelqu'un capte les _deux_ données ?
Si on crypte un fichier, c'est parce qu'il risque d'être intercepté d'une manière ou d'une autre. Or, ta clef est un fichier, et donc il est tout aussi probable qu'elle se fasse récupérer que ton fichier.

Si tu trouves un moyen sûr de transférer une clef, sans qu'elle se fasse intercepter / déchiffrer, alors tu auras révolutionné la sécurité informatique. En attendant, tout système est à considérer comme faillible.

Commentaire de X_Cli le 29/11/2010 17:08:32

@attreid: le chiffrement asymétrique n'est pas nouveau, il existe depuis presque 40 ans, donc ce n'est pas révolutionnaire. On se sert du chiffrement asymétrique précisément pour transférer les clés de (dé)chiffrement pour pouvoir ensuite faire du chiffrement symétrique qui est bcp plus performant.
On peut critiquer surement bcp de choses sur cette source, mais pas le choix du chiffrement symétrique :)

Commentaire de gaumerie le 30/11/2010 19:03:03

Si je peux me permettre, par curiosité, quel âge as-tu?

Commentaire de underprog le 01/12/2010 15:51:19

et si on fait une attaque par header ? on peut facilement retrouver la clé, non? surtout ici avec l'exemple d'un mp3...

Commentaire de LeFauve42 le 02/12/2010 11:17:05 1/10

>  et si on fait une attaque par header ? on peut facilement retrouver la clé, non? surtout ici avec l'exemple d'un mp3...

Oui, c'est ca dont je parlais dans mon premier post :
> Une petite remarque: si en plus tu veux crypter des fichiers (et non de l'information brute), il y a des mesures supplementaires a prendre, comme ne surtout pas crypter l'entete du fichier (celui-ci est facilement deductible, ce qui va compromettre une bonne partie de ta cle).

La procedure est :
-1) Avec une partie du message "en clair" (le header) on peut determiner une partie de la cle.
-2) Cette partie de la cle permet de decoder une partie du message.
-3) A partir de morceaux en clair du message, on peut deduire certaines parties du texte (ex: si tu as un bout de phrase comme "Cher Mons@#$$@#$#%" tu peux facilement deduire que les 4 premiers caracteres manquants sont "ieur" (suivi probablement d'une virgule ou d'un espace)).
-4) Avec cette nouvelle partie du message "clair", on peut completer un bout de la cle et revenir au "-2)" jusqu'a obtention du message complet.

Commentaire de lilington le 07/12/2010 08:15:05

salut!
je programme generalement en C et rarement en C++ ca fait si vous verifier des annees que j'ai pas poste ni une source ni un commentaire(meme si je lis souvent des sources). j'ai lu cette source et TOUS les commentaires.
Je n'y connais rien en chiffrement/cryptage (meme en vocabulaire :)) mais faut reconnaitre que l'auteur est sur la defensive et pas pres a ecouter les critiques notemment celle de LeFauve42 qui a l'aire de s'y connaitre.
celle du debut donnaient l'impression de repondre a l'arogance de l'auteur qui au vu de ce que j'ai lu et au passage j'ai secret and lies que j'ai immediatement lu, l'auteur de notre code s'entete et s'aveugle.
Oui les commentaires sont agressif, sauf pour LeFauve42 sont assez dure a prendre quand on s'est mit soit meme tres haut. mais oui ils disent la verite. et meme moi qui m'y connait pas trop j'ai compris la difference entre ce que tu dis et ce qu'on te demande.
en un mot acceptes que tu as pas tout a fait raison sur ce coup la et ce que j'aurai fait a ta place c'est lire plus sur le sujet poster un code et demander l'avis des autres de maniere un peu plus humble et crois moi tu apprendras plus.

 Ajouter un commentaire


Discussions en rapport avec ce code source dans le forum

Encryption 128 bit [ par GEDEON ] Quelqu'un aurait-il des informations pour encrypter un fichier en c++ ???? et de préférence en 128 bits... toutes les informations sont les bienvenues Encryption 128 bit [ par GEDEON ] Quelqu'un aurait-il des informations pour encrypter un fichier en c++ ???? et de préférence en 128 bits... toutes les informations sont les bienvenues cryptage RSA [ par moicmoi ] Bon je me doute que je vais passer pour un boulet mais j'aurai besoin avant jeudi d'un code source du cryptage RSA en LANGAGE C. Mais un code tout si Cryptage RSA [ par ritchie00 ] Salut,Qqun saurait où je peux trouver une API C++ de chiffrement/dechiffrement RSA, qui marcherait avec des certificats et des tailles de clés paramét Pb de sécurité... [ par wanny ] Bonjour.Je travaille sur une nouvelle version d'un logiciel commercial.Actuellement, la licence de ce logiciel est généré en fonction du nom de la mac Le cryptage par MD5 de RSA [ par LSRS ] Salut tout le monde...J'ai un très grand problème avec l'algorithme de hachage MD5 qui réprésente le squelette de mon stage d'été... Je n'arrive pas à sécurité contre les boucles infinies? [ par mikolaj ] Salut,je développe en C sous Mac osX et j'implémente actuellement un programme utilisant des nombres générés par random qui sont ensuite rejetés ou c Projet de sécurité [ par UniCyclon ] Salut,Je représente Sy-Labs, une assoc globale basée sur les technologies informatiques, et plus particulièrement Subria, qui a pour but d'augmenter l Amateur de stéganographie et de sécurité ? [ par NikatorS ] A tous ceux qui se pationne de stéganographie, je continu un projet qui me tien à coeur : caché toujours mieux des données.Je viens d'améliorer un pro RSA [ par james007bond1980 ] Bonjour &#224; tous et &#224; toutes!je souhaite coder et d&#233;coder&nbsp;un mot par exemple:"salut" avec le cryptage RSA en C.Comment faire? je sui


Nos sponsors


Sondage...

CalendriCode

Mai 2013
LMMJVSD
  12345
6789101112
13141516171819
20212223242526
2728293031  

Consulter la suite du CalendriCode

Photothèque

A découvrir



 
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 : 1,186 sec (4)

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