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é.

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

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 :

1. Surcharge io_uring par SQE : chaque bloc nécessite un SQE de lecture et un SQE d'écriture. Avec 256 blocs pour un fichier de 256 Mio, cela représente 512 SQE soumis et 512 CQE récupérés. Bien que io_uring évite le coût de transition noyau par appel système de pread/pwrite, il a toujours une surcharge de tampon circulaire et de barrière mémoire par SQE.
2. Profondeur du pipeline : Avec PIPELINE_DEPTH=3, seulement trois lots tournent dans le pipeline à tout moment. Un véritable régime permanent de chevauchement nécessite au moins trois lots ; les fichiers qui tiennent dans un ou deux lots ne bénéficient pas du pipeline.
3. Effets de hiérarchie de cache : Le 5600X a 512 Kio de L2 par cœur et 32 Mio de L3 partagée. Le bloc par défaut de 4 Mio dépasse la L2, et un lot d'environ 21 blocs (84 Mio d'ensemble de travail actif) dépasse largement la L3. Les tailles de bloc plus petites (64-256 Kio) montrent un meilleur débit dans le balayage car une plus grande partie de l'ensemble de travail reste dans le cache.

Cycle de vie et sécurité des tampons : Les pools de tampons sont alloués une fois via std::alloc::alloc_zeroed avec Layout::from_size_align(size, 4096) avant que l'anneau io_uring ne soit créé, et sont réutilisés à travers toutes les itérations du pipeline sans réallocation. Chaque bloc chiffré est rembourré de zéros jusqu'à l'alignement de secteur avant l'écriture O_DIRECT. L'anneau est explicitement libéré avant les pools de tampons, garantissant que le noyau ne référence jamais de mémoire libérée (pas d'UAF).

Installation

git clone https://github.com/frogsnot/concryptor.git
cd concryptor
cargo build --release

Le binaire se trouve dans target/release/concryptor.

Utilisation

Chiffrer

# AES-256-GCM (par défaut), sortie vers myfile.dat.enc
concryptor encrypt myfile.dat

# ChaCha20-Poly1305, chemin de sortie personnalisé
concryptor encrypt myfile.dat --cipher chacha -o encrypted.enc

# Taille de bloc personnalisée (en Mio)
concryptor encrypt largefile.iso --chunk-size 8

# KDF plus fort (coût mémoire 512 Mio)
concryptor encrypt secrets.tar --memory 512

# Non interactif (saute l'invite de mot de passe)
concryptor encrypt myfile.dat -p "password"

Note de sécurité : --password / -p transmet le mot de passe comme argument CLI, visible dans la sortie ps et l'historique du shell. Pour une utilisation interactive, omettez-le pour obtenir l'invite sécurisée masquée. Pour les scripts, privilégiez l'effacement de l'historique après ou l'utilisation d'un wrapper qui lit à partir d'un descripteur de fichier.

Chiffrer un répertoire

# Chiffre un répertoire (détection automatique, produit mydir.tar.enc)
concryptor encrypt mydir/

# Avec cipher et sortie personnalisés
concryptor encrypt mydir/ --cipher chacha -o secrets.enc

Le chiffrement de répertoire crée une archive tar temporaire (.concryptor-*.tar, permissions 0600, nommé avec CSPRNG), la chiffre, puis supprime automatiquement le fichier temporaire. Les noms de fichiers, la structure des répertoires, les permissions et les horodatages sont tous à l'intérieur de la charge utile chiffrée.

Déchiffrer

# Supprime automatiquement l'extension .enc
concryptor decrypt myfile.dat.enc

# Chemin de sortie personnalisé
concryptor decrypt encrypted.enc -o restored.dat

# Non interactif
concryptor decrypt myfile.dat.enc -p "password"

Déchiffrer et extraire un répertoire

# Déchiffre et extrait en une seule étape (supprime automatiquement .tar.enc -> nom du répertoire)
concryptor decrypt mydir.tar.enc --extract

# Option courte, répertoire de sortie personnalisé
concryptor decrypt mydir.tar.enc -x -o restored_dir/

Sans --extract, le déchiffrement d'une archive de répertoire produit le fichier .tar intermédiaire, que vous pouvez inspecter ou extraire manuellement.

Aide

concryptor --help
concryptor encrypt --help
concryptor decrypt --help

Format du fichier

Toutes les valeurs sont en little-endian. L'en-tête occupe un secteur complet de 4 Kio ; chaque emplacement de bloc chiffré est rembourré jusqu'à la limite de 4 Kio suivante. Cela garantit que chaque décalage et taille d'E/S est aligné sur le secteur pour O_DIRECT.

Décalage  Taille   Champ
--------  ------   ---------------------
0         10       Octets magiques "CONCRYPTOR"
10         1       Version du format (4)
11         1       Type de cipher (0 = AES-256-GCM, 1 = ChaCha20-Poly1305)
12         4       Taille de bloc (octets, LE)
16         8       Taille originale du fichier (octets, LE)
24        16       Sel Argon2 (cryptographiquement aléatoire, unique par fichier)
40        12       Nonce de base (cryptographiquement aléatoire, unique par fichier)
52         4       Coût m_cost Argon2 en Kio (LE, 0 = héritage 64 Mio)
56         4       Coût t_cost / itérations Argon2 (LE, 0 = héritage 3)
60         4       Coût p_cost / parallélisme Argon2 (LE, 0 = héritage 4)
64       4032     Réservé (rembourré de zéros jusqu'à 4096 octets)
4096      ...     [Bloc 0 : texte chiffré + étiquette de 16 octets + rembourrage de zéros jusqu'à la limite de secteur]
                  [Bloc 1 : texte chiffré + étiquette de 16 octets + rembourrage de zéros jusqu'à la limite de secteur]
                  ...

Pour des blocs de 4 Mio : chaque emplacement disque fait ceil((4194304 + 16) / 4096) * 4096 = 4198400 octets (4080 octets de rembourrage par bloc). Les 4032 octets réservés dans l'en-tête sont disponibles pour des fonctionnalités futures (emplacements de clé asymétrique, métadonnées, etc.).

Le sel et le nonce de base sont générés fraîchement à partir de rand::rng() (backé par le CSPRNG du système) à chaque chiffrement. Réutiliser un mot de passe entre fichiers est sûr car des sels différents produisent des clés Argon2id différentes, et des nonces de base différents produisent des nonces par bloc différents.

Conception de sécurité

• Dérivation du nonce : nonce_bloc = nonce_de_base XOR index_bloc (style TLS 1.3). Échanger des blocs provoque un échec de déchiffrement car le nonce à la position N ne correspondra pas au nonce utilisé pour chiffrer le bloc originellement à la position M. Note : la dérivation de nonce par XOR a une faiblesse théorique lorsque la même clé est utilisée à travers plusieurs flux (des nonces de base distincts peuvent produire des espaces de nonces qui se chevauchent). Cela ne s'applique pas à Concryptor car chaque chiffrement génère un sel aléatoire frais de 128 bits, produisant une clé Argon2id unique par fichier. L'unicité du nonce n'a d'importance que sous la même clé, et la probabilité de réutilisation de clé est ~2^-128 par paire de fichiers.
• AAD authentifié par l'en-tête : Chaque appel AEAD de bloc utilise AAD = en-tête_complet_aligné (4096) || index_bloc (8 LE) || est_final (1) (4105 octets au total). L'ensemble du secteur d'en-tête de 4 Kio (champs de base, paramètres KDF et rembourrage réservé) est lié à l'étiquette d'authentification de chaque bloc. Modifier un quelconque octet de l'en-tête (type de cipher, taille de bloc, taille originale, sel, nonce, paramètres KDF ou rembourrage réservé) invalide tous les blocs. Cela empêche les attaques de troncature où un adversaire édite original_size et supprime les blocs de fin, et empêche également la contrebande de données dans la région de rembourrage réservé. Les fichiers hérités v3 sont déchiffrés avec un AAD de 52 octets pour la rétrocompatibilité ; aucun downgrade de v4 à v3 n'est possible car l'octet de version lui-même est dans l'AAD authentifié.
• Indicateur de dernier bloc de style STREAM : Le dernier octet de l'AAD est 0x01 pour le dernier bloc et 0x00 pour tous les autres. Cela empêche deux attaques :
  • Troncature : Supprimer le dernier bloc et promouvoir un bloc non final à la fin échoue car le bloc non final a été chiffré avec mais le déchiffrement attend .

Tests

# Exécute la suite de tests complète (67 tests)
cargo test

# Exécute les benchmarks (rapports HTML dans target/criterion/)
cargo bench

# Filtrer les benchmarks
cargo bench -- "encrypt/AES"
cargo bench -- "chunk_sweep"

La suite de tests couvre :

• Allers-retours de sérialisation/désérialisation de l'en-tête
• Déterminisme et sensibilité de la dérivation de clé
• Propriétés d'unicité et d'identité du nonce
• Allers-retours chiffrement/déchiffrement pour les deux ciphers sur des tailles de fichier (vide, 1 octet, cas limites, multi-blocs)
• Rejet de mot de passe incorrect
• Détection de falsification (texte chiffré retourné, étiquettes corrompues, sel corrompu, fichiers tronqués)
• Détection d'attaque de réorganisation de blocs
• Détection de non-concordance de type de cipher
• Détection d'attaque de troncature (original_size modifié + blocs supprimés)
• Détection de manipulation de champ d'en-tête (chunk_size modifié)
• Détection de falsification des octets réservés de l'en-tête (région de rembourrage modifiée)
• Vérification de chiffrement non déterministe
• Test de stress avec 256 petits blocs
• Allers-retours d'archive de répertoire (pack/unpack) pour les deux ciphers
• Répertoire vide, répertoire profondément imbriqué, nombreux fichiers, et contenu binaire
• Préservation des liens symboliques pour les liens internes valides
• Rejet des liens symboliques s'échappant de la racine d'extraction (traversée absolue et relative)
• Nettoyage automatique du fichier temporaire lors du Drop
• Rejet de mot de passe incorrect pour les archives chiffrées

Dépendances

Installer

# Depuis crates.io (recommandé)
cargo install concryptor

# Depuis les sources
git clone https://github.com/FrogSnot/Concryptor
cd Concryptor
cargo build --release
# Le binaire se trouve dans target/release/concryptor

Licence

Ce projet est sous licence GNU Affero General Public License v3.0.