Encryptix
Trois chiffrements derrière un seul service, et une empreinte aux deux bouts pour prouver que le fichier est revenu intact.
- Année
- Cadre
- Domaine
Le parcours d’une requête
- Entrée: Un dossier, lu récursivement en octets - Windows Forms
- Orchestration: Service WCF - WCF, .NET
- En parallèle
- AES - CBC, bibliothèque .NET - .NET
- RC6 - Implémenté à la main, 20 tours - C#
- XXTEA - Implémenté à la main, réseau de Feistel - C#
- Sortie: Un fichier chiffré par fichier d’entrée - Empreinte SHA-512 enregistrée avant et après
Aperçu
Ici, on travaille sur un dossier, pas sur un fichier. Vous indiquez un répertoire à l’application, elle lit tout son contenu, sous-dossiers compris, puis l’un des trois chiffrements symétriques traite l’ensemble. L’arborescence chiffrée, l’arborescence déchiffrée et le journal des empreintes sont écrits chacun à l’emplacement de votre choix.
S’il y en a trois, c’est qu’un seul était fourni tout fait. AES est l’implémentation de la bibliothèque .NET, celle que toute application raisonnable utiliserait. RC6 et XXTEA sont implémentés d’après leur spécification, et c’est là qu’était le vrai travail : l’expansion de la clé, le remplissage des blocs, les rotations et le dépassement d’entier volontaire sur lequel repose XXTEA.
Technologies
- Client
- Windows FormsC#
- Service
- WCF.NETC#
Architecture
Le client lit le dossier
Une boîte de dialogue, puis un parcours récursif qui lit chaque fichier en octets bruts, quelle que soit son extension, et regroupe son nom, son extension, son répertoire et son contenu dans un seul enregistrement. Le contenu n’est jamais interprété : un .txt et un .exe suivent le même chemin dans le programme.
Une tâche de fond pour ne pas figer la fenêtre
Sous Windows Forms, l’application n’a qu’un seul thread, et c’est lui qui possède les contrôles : lire un gros dossier sur ce thread figerait la fenêtre, et avec elle l’indicateur qu’elle est censée afficher. La lecture s’exécute donc dans une Task, et la continuation est replanifiée sur le contexte de synchronisation du formulaire, le seul endroit d’où l’on a le droit de réactiver les boutons.
La liste passe au service
Le client appelle le service WCF en HTTP. Les deux côtés ont dû être reconfigurés pour la taille des messages : les limites de tampon sont portées à la valeur maximale d’un int, et le mode de transfert passe de Buffered à Streamed, pour que seul l’en-tête du message soit mis en tampon et non toute la liste des fichiers, avec un délai d’expiration de dix minutes de chaque côté.
Le service chiffre, fichier par fichier
L’algorithme choisi reçoit la liste, la clé et - pour AES - le vecteur d’initialisation. RC6 et XXTEA exigent que leur entrée remplisse des blocs entiers, donc chacun complète le tableau d’octets jusqu’à sa taille de bloc et inscrit la longueur d’origine dans les quatre premiers octets, ce qui permet au déchiffrement de retirer ce remplissage au lieu de devoir deviner où le fichier s’arrêtait.
Une empreinte à chaque bout
À côté de chaque fichier, un fichier texte contient quatre empreintes SHA-512 : avant chiffrement, après chiffrement, avant déchiffrement, après déchiffrement. Ce sont la première et la dernière qui comptent, et elles doivent être identiques. Toute la garantie d’intégrité est là, et n’importe qui peut la vérifier en ouvrant le fichier.
Fonctionnalités
Un dossier entier d’un coup
Sous-dossiers compris, à n’importe quelle profondeur. L’arborescence de sortie reproduit celle d’entrée : elle est calculée à partir du chemin de chaque fichier relatif à la racine, et non en suivant la récursion.
Trois chiffrements, un formulaire
AES avec une clé de 32 caractères et un IV de 16, RC6 et XXTEA avec des clés de 16 caractères. Chacun a sa fenêtre, et chaque champ est validé avant toute écriture.
La preuve de l’aller-retour
L’empreinte SHA-512 du texte clair avant chiffrement, comparée à celle du texte clair après déchiffrement. Si elles sont égales, l’aller-retour s’est fait sans perte.
Séquentiel ou parallèle
Les deux modes sont disponibles, et une case à cocher permet de choisir. En mode parallèle, la liste des fichiers est répartie sur une boucle parallèle, et comme aucun fichier ne dépend d’un autre, il n’y a rien à verrouiller ni à fusionner. Les résultats ci-dessous chiffrent le gain.
Une barre de progression qui finit avec le traitement
Elle avance au rythme du nombre total d’octets pendant que le service travaille, et se remplit dès que l’appel réel revient, grâce à un jeton d’annulation : elle suit le traitement et se termine avec lui, pas après.
L’arborescence d’abord
Une arborescence de tout ce qui a été chargé, entièrement dépliée, pour vérifier ce qui va être chiffré avant de lancer l’opération.
Résultats
| Mode | Fichiers | Chiffrement (s) | Déchiffrement (s) |
|---|---|---|---|
| Séquentiel | 150 | 68,91 | 70,13 |
| Parallèle | 150 | 44,16 | 40,39 |
Les mêmes 150 fichiers, la même clé RC6, les mêmes dossiers de sortie, une exécution dans chaque mode. Le chiffrement parallèle a pris 44,16 secondes contre 68,91, et le déchiffrement 40,39 contre 70,13 : plus d’un tiers de moins dans les deux sens.
Le gain vient de l’indépendance des fichiers : la boucle parallèle n’a besoin ni de verrou ni d’ordre, et aucun fichier n’attend le précédent.
Ce que j’en retiens
Le projet avait pour but d’implémenter deux des trois chiffrements plutôt que de les appeler. Ce sont des algorithmes courts où presque chaque ligne compte : le sens d’une rotation, l’endroit où est stockée la longueur d’origine, et le fait que XXTEA exige que son arithmétique déborde au lieu de lever une erreur. Les empreintes identiques prouvent que tout est juste, octet par octet.
L’autre volet du projet, c’est la séparation client-serveur. La cryptographie s’exécute dans le service et non dans le processus qui affiche la fenêtre, et les trois algorithmes sont disponibles pour tout autre programme capable d’appeler ce service.