:: Enseignements :: ESIPE :: E3INFO :: 2010-2011 :: Programmation C ::

CryptKeeper (IR1 et OC1)

But du projet

La seule méthode cryptographique inattaquable consiste à utiliser une clé aussi longue que le message que l'on veut crypter. Ainsi, si l'on fait un simple XOR bit à bit entre le message et la clé, on obtiendra quelque chose d'impossible à décrypter sans la clé, puisqu'en parcourant toutes les clés possibles, on obtiendrait tous les messages possibles sans aucun indice permettant de savoir lequel est le bon. De plus, le XOR ayant la sympathique propriété d'être réversible, il suffit de refaire un XOR bit à bit entre le message crypté et la clé pour retrouver le message d'origine. Votre objectif est d'implémenter un programme de cryptage/décryptage basé sur ce principe.

Note: afin d'éviter de vous faire trucider par votre professeur d'algorithimique, il est bon que vous sachiez tout de même que cette méthode n'est inattaquable que si la clé est composée de données aléatoires. Dans la vraie vie, on utilise des CD de bruit à usage unique pour ce genre d'opérations.

La clé

En guise de clé, votre programme utilisera un fichier, qui devra bien sûr être au moins aussi long que le fichier à crypter. Evidemment, puisque tout repose sur la clé, il n'est pas question de la diffuser avec le message crypté. Nous allons donc utiliser des fichiers trouvés sur le web, et la clé sera représentée par son URL en http://. Vous récupérerez la clé grâce au programme wget, invoqué avec la fonction system, à moins que vous ne soyez de grosses brutes décidées à coder vous-même la récupération du fichier via une socket TCP.

Dans un souci d'utilisabilité, votre programme devra aussi accepter les fichiers locaux. Le critère sera donc le suivant: si le nom de la clé commence par http://, c'est l'URL d'un fichier à télécharger, sinon c'est le nom d'un fichier local.

Pour vos tests, vous pourrez utiliser l'url suivante: http://igm.univ-mlv.fr/~paumier/cryptkeeper.key

Le chat

Le problème avec un fichier pris sur le web, c'est qu'il peut changer sans préavis, ce qui ruinerait notre protocole. Pour éviter cela, nous allons calculer une somme de contrôle sur la clé grâce à l'algorithme SHA256. Cet algorithme produit une somme de 32 octets. Il est implémenté dans la bibliothèque libgcrypt que vous devrez utiliser.

Multi-fichiers

Dans le cas où l'utilisateur veut crypter plusieurs fichiers en une seule fois, vous utiliserez la bibliothèque libtar pour créer une archive .tar que vous crypterez ensuite.

Format de cryptage

Comme on ne veut donner aucune information sur le fichier de départ, on veut également crypter son nom (sans le chemin). Le format d'un fichier crypté sera donc le suivant:

+--------+-----------+------+-----+------+
| SHA256 | SIZE_NAME | NAME | TAR | DATA |
+--------+-----------+------+-----+------+

SIZE_NAME correspond à la longueur du nom de fichier codé sur deux octets en little-endian. NAME correspond au nom du fichier en ASCII, sans le \0 final. TAR est un octet valant 1 si le fichier est une archive tar qui devra être décompressée, 0 sinon. DATA correspond au contenu du fichier de départ. Le cryptage avec un XOR sur la clé doit porter sur tout, sauf l'en-tête SHA256. Vérifiez bien que votre clé est assez longue pour les données plus ce qu'il faut pour stocker le nom du fichier.

Conditions de développement

Le but de ce projet est moins de pondre du code que de développer le plus proprement possible. C'est pourquoi, vous développerez ce projet sur le serveur CVS de l'université. Comme nous attendons de vous que vous le fassiez sérieusement, votre rendu devra contenir un dump du fichier de logs de votre projet CVS, afin que nous puissions nous assurer que vous avez bien développé par petites touches successives et propres (commits bien commentés), et non pas avec un seul commit du résultat la veille du rendu.

Conditions de rendu

Vous travaillerez en binômes, et vous lirez pour un profit maximum la charte des projets. Vous ne rendrez pas votre projet au moyen d'une archive, mais avec un package Debian. Le rendu consistera donc en un mail dans lequel vous donnerez l'URL de votre repository, qui devra se trouver sur votre compte web de l'université. Le test de votre projet se fera alors avec la commande:

sudo apt-get install cryptkeeper

La commande cryptkeeper doit alors être installée et doit pouvoir permettre le cryptage et décryptage de fichiers selon la syntaxe suivante:

cryptkeeper -c/--crypt cle fic1 [fic2 ...]

Par défaut, la commande produira un fichier crypt.bin, mais on devra pouvoir spécifier le nom du fichier de sortie avec -o ou --output. Si aucun fichier n'apparaît en argument de la ligne de commande, les noms des fichiers seront lus depuis l'entrée standard. Dans ce dernier cas, vous ferez bien attention à pouvoir gérer sans erreur mémoire une liste de noms de fichiers arbitrairement grande.

cryptkeeper -d/--decrypt cle bin

Cette fonction décrypte le fichier bin en recréant le ou les fichiers de départ, avec leurs noms d'origine.

Naturellement, toutes les options que vous proposerez (ne serait-ce que --help) devront être gérées avec getopt_long. Votre package devra correctement gérer les dépendances, de façon à récupérer les bibliothèques libgcrypt et libtar si elles ne se trouvent pas déjà sur le système, idem pour le programme wget.

Afin de pouvoir accéder aux sources de votre travail, vous préparerez également un package source contenant les choses suivantes:

un répertoire src contenant les sources du projet ainsi qu'un Makefile. Lorsqu'on lance make, on doit obtenir un exécutable nommé cryptkeeper. La cible clean doit fonctionner correctement. Les sources doivent être propres, en anglais et commentées.
un fichier cvs_logs correspondant au dump des logs de votre projet CVS
un fichier doc.pdf contenant votre rapport qui devra décrire votre travail. En particulier, vous décrirez avec soin votre façon de gérer correctement la liste de fichiers quand elle doit être lue depuis l'entrée standard. Si votre projet ne fonctionne pas complètement, vous devrez en décrire les bugs.

Comme pour l'exécutable, l'accès à votre package source se fera au moyen de apt-get:

apt-get source cryptkeeper

En dehors des 2 bibliothèques mentionnées, il est interdit d'utiliser du code externe: vous devrez tout coder vous-mêmes.
Tout code commun à plusieurs projets vaudra zéro pour tous les projets concernés.

Le projet est à rendre par mail à tous les enseignants (Mathieu Constant et Sébastien Paumier pour les IR1, Sylvain Cherrier et Sébastien Paumier pour les OC1), au plus tard le lundi 16 mai 2011 à 23h.