Concryptor

Un moteur de chiffrement AEAD multi-threadé construit en Rust. Chiffre et déchiffre des fichiers à un débit de gigaoctets par seconde grâce à un pipeline io_uring triple-bufferisé, un traitement par blocs parallèle via Rayon, et des ciphers optimisés en assembleur via ring.

⚠️ AVERTISSEMENT : LOGICIEL EXPÉRIMENTAL ⚠️

Ce projet est extrêmement récent et n'est actuellement PAS recommandé pour une utilisation en production ou pour des données critiques. Bien que les primitives cryptographiques (AES-256-GCM, ChaCha20-Poly1305 via ring) et la conception du format soient solides, la base de code n'a pas fait l'objet d'audits de sécurité formels ni de tests approfondis en conditions réelles. Utilisez-le à vos risques et périls. Pour protéger des données sensibles, privilégiez des outils éprouvés comme GnuPG, age ou OpenSSL jusqu'à ce que ce projet mûrisse.

Fonctionnalités

• Prise en charge de deux ciphers : AES-256-GCM (AES-NI matériel) et ChaCha20-Poly1305 via ring (optimisé en assembleur)
• Chiffrement parallèle : traitement par blocs multi-threadé via Rayon sur tous les cœurs du processeur
• Pipeline io_uring triple-bufferisé : superpose les E/S du noyau et la cryptographie côté CPU à l'aide de trois pools de tampons rotatifs — pendant que les écritures d'un lot sont en cours dans le noyau, le lot suivant est chiffré par Rayon sur le CPU, et les lectures du troisième lot sont soumises au noyau. Pas de surcharge syscall par bloc, pas de limitations mmap (pas de SIGBUS, pas d'épuisement de l'espace d'adressage virtuel)
• Dérivation de clé Argon2id : étirement mot de passe-à-clé standard industriel (256 Mio de mémoire par défaut, 3 itérations, configurable via --memory)
• Paramètres KDF auto-descriptifs : le coût mémoire, les itérations et le parallélisme sont stockés dans l'en-tête du fichier chiffré, de sorte que le déchiffrement utilise exactement les paramètres choisis au moment du chiffrement. Les fichiers hérités (sentinel tous à zéro) sont traités de manière transparente avec les anciennes valeurs par défaut de 64 Mio
• Nonces indexés par bloc : dérivation de nonce par XOR de style TLS 1.3 empêchant les attaques de réorganisation des blocs
• AAD authentifié par l'en-tête : l'en-tête complet aligné sur 4 Kio est inclus dans l'AAD de chaque bloc, authentifiant tous les champs de l'en-tête (noyau, paramètres KDF et octets réservés) et empêchant les attaques de troncature, de manipulation des champs d'en-tête et de contrebande d'octets réservés
• Dernier bloc de style STREAM : un indicateur de dernier bloc dans l'AAD empêche les attaques de troncature et d'extension (inspiré de la construction STREAM)
• Aléatoire frais par fichier : un sel cryptographique aléatoire de 16 octets et un nonce de base de 12 octets sont générés pour chaque chiffrement, stockés dans l'en-tête
• Chiffrement sur place : seal_in_place_separate_tag / open_in_place via ring minimise les allocations dans la boucle chaude
• Zéroïsation des mots de passe : les clés et mots de passe sont effacés de manière sécurisée de la mémoire après utilisation
• O_DIRECT + format aligné sur secteur : en-tête aligné sur 4 Kio et emplacements de blocs permettant les E/S O_DIRECT, contournant le cache de page du noyau pour des lectures/écritures à vitesse DMA sur NVMe. Les pools de tampons utilisent std::alloc avec un alignement de 4096 octets
• Chiffrement de répertoires : chiffre des répertoires entiers sous forme d'archive chiffrée unique. L'empaquetage basé sur tar préserve les noms de fichiers, les permissions, les horodatages et la structure des répertoires dans le texte chiffré. L'extraction valide contre les attaques de traversée de chemin et d'échappement de lien symbolique
• Format de fichier auto-descriptif : l'en-tête stocke le cipher, la taille de bloc, la taille originale du fichier, le sel, le nonce de base et les paramètres KDF Argon2id

Performances

Benchmarké avec cargo bench (Criterion, 10 échantillons par mesure). La dérivation de clé est exclue — les chiffres reflètent uniquement le débit cryptographique pur.

Matériel :

• CPU : AMD Ryzen 5 5600X (6c/12t @ 3.7 GHz de base)
• RAM : 2× 8 Gio DDR4-2666 (double canal, 16 Gio au total)
• OS : Linux

Note sur les E/S : Criterion écrit des fichiers temporaires dans /tmp, qui sur ce système est tmpfs (backé par la RAM). Avec O_DIRECT, le noyau ne peut pas utiliser le véritable DMA asynchrone sur tmpfs, donc ces chiffres reflètent le débit du cipher + la surcharge de io_uring sans l'avantage du contournement DMA. Sur un véritable disque NVMe Gen4, O_DIRECT élimine la double mise en cache du cache de page et permet le DMA directement dans les pools de tampons alignés, ce qui devrait donner un débit nettement plus élevé.

Taille du fichier	Chiffrement AES-256-GCM	Chiffrement ChaCha20	Déchiffrement AES-256-GCM	Déchiffrement ChaCha20
64 Kio	244 Mio/s	233 Mio/s	233 Mio/s	234 Mio/s
1 Mio	1,08 Gio/s	882 Mio/s	1010 Mio/s	876 Mio/s
16 Mio	1,10 Gio/s	923 Mio/s	1,06 Gio/s	988 Mio/s
64 Mio	984 Mio/s	935 Mio/s	988 Mio/s	973 Mio/s
256 Mio	1,00 Gio/s	1015 Mio/s	1,01 Gio/s	1,02 Gio/s

Balayage de la taille de bloc (AES-256-GCM, fichier de 64 Mio) :

Taille de bloc	Débit
64 Kio	1,01 Gio/s
256 Kio	1,05 Gio/s
1 Mio	1,07 Gio/s
4 Mio	988 Mio/s
8 Mio	988 Mio/s
16 Mio	1,00 Gio/s

Caractéristiques de performance

Le moteur utilise ring (AES-NI / NEON / ARMv8-CE optimisé en assembleur) pour les opérations de cipher et un pipeline io_uring triple-bufferisé pour les E/S. Trois pools de tampons pré-alloués tournent dans le pipeline : pendant que les écritures du pool A se terminent dans le noyau, le pool B est chiffré par Rayon sur le CPU, et les lectures du pool C sont soumises au noyau. Cela superpose la latence des E/S avec le calcul cryptographique.

Pourquoi AES-256-GCM est plus rapide que ChaCha20-Poly1305 sur les petits fichiers : Le backend AES-GCM de ring exploite les instructions matérielles AES-NI + CLMUL disponibles sur x86-64, ce qui lui donne un avantage matériel par rapport à ChaCha20 (qui est un cipher logiciel). Pour les grandes tailles, les deux ciphers convergent vers ~1,0 Gio/s, indiquant que le goulot d'étranglement passe du débit du cipher à la surcharge de soumission des E/S.

Pourquoi le débit de pointe est à 1-16 Mio, pas à 256 Mio : Les petits fichiers (1-16 Mio) ont peu de blocs, donc le parallélisme Rayon est efficace et l'ensemble de travail tient dans le cache. À 64-256 Mio, le pipeline io_uring est pleinement actif (trois lots en vol), mais la surcharge de soumission SQE et de récupération CQE augmente avec le nombre de blocs. La conception triple-buffer garantit le chevauchement des E/S et de la cryptographie, masquant partiellement ce coût.

Pourquoi ~1,0 Gio/s et pas 10+ Gio/s : L'AES-NI moderne peut pousser 2-4 Gio/s par cœur. Avec 12 threads, le débit brut du cipher pourrait dépasser 10 Gio/s. Trois facteurs expliquent l'écart :