🏠 Accueil    📑 Spécification    📜 page de manuel    📄 Options d’entrée    📖 Tutoriel    ❓ FAQ    📥 Installer

tird & tirdFS

tird /tɪrd/ (un acronyme pour « ce sont des données aléatoires ») est un outil de chiffrement de fichiers qui minimise les métadonnées et cache les données chiffrées.

Avec tird, vous pouvez :

1. Créer des fichiers remplis de données aléatoires à utiliser comme conteneurs ou fichiers de clés.
2. Remplacer le contenu des périphériques en mode bloc et des fichiers ordinaires par des données aléatoires pour préparer des conteneurs ou détruire les données résiduelles.
3. Chiffrer le contenu des fichiers et les commentaires avec des fichiers de clés et des phrases de passe. Le format des données chiffrées (cryptoblob) est un blob aléatoire uniforme rembourré (PURB) : il ressemble à des données aléatoires et a une taille aléatoire. Cela réduit la fuite de métadonnées liées au format et à la longueur du fichier et permet de cacher les cryptoblobs parmi les données aléatoires.
4. Créer des systèmes de fichiers dirigés par l’utilisateur stéganographiques (cachés, indétectables) (tirdFS) à l’intérieur de fichiers conteneurs et de périphériques en mode bloc. Contrairement à VeraCrypt et Shufflecake, les conteneurs tirdFS ne contiennent pas d’en-têtes ; l’utilisateur spécifie les emplacements des données à l’intérieur du conteneur et est responsable de maintenir ces emplacements séparés. Toute région d’apparence aléatoire d’un fichier ou d’un périphérique en mode bloc peut être utilisée comme conteneur.
5. Empêcher l’accès rapide aux données déchiffrées en utilisant le chiffrement à verrou temporel.

tird offre un déni plausible intégré, même lorsque les fichiers chiffrés sont stockés en dehors des conteneurs. Il aide également à résister aux attaques coercitives de divulgation de clé (cryptanalyse sous pression, xkcd 538).

[!ATTENTION] Avant d’utiliser tird, veuillez lire la section « Avertissements ». La sécurité ne dépend pas seulement de l’outil mais de vos actions : stockage sécurisé des clés, utilisation dans un environnement sûr, et évitement du mode débogage avec des données réelles.

La stabilisation du format et une spécification formelle sont prévues pour la v1.0.0.

Objectifs

1. Protection des fichiers : Assurer la protection des fichiers individuels, notamment :
   • Confidentialité et intégrité à l’aide du chiffrement symétrique authentifié.
   • Minimiser la fuite de métadonnées, y compris en cachant la présence de données chiffrées.
   • Prévenir ou résister aux attaques coercitives.
2. Format stable : Maintenir un format de données chiffrées stable sans agilité cryptographique pour le stockage à long terme.
3. Simplicité : Prioriser la simplicité et éviter l’inflation des fonctionnalités ; refuser d’implémenter des fonctionnalités non directement liées aux objectifs de sécurité principaux.

Fonctionnalités

• Blobs chiffrés au format PURB : taille aléatoire et contenu uniformément aléatoire ; métadonnées limitées (seule la taille totale fuit — pas d’en-têtes, de types ou d’indications en clair).
• Commentaires rembourrés et chiffrés : aucune indication en clair sur le contenu.
• Intégration de données cachées (optionnelle) : dissimuler les cryptoblobs dans des conteneurs aléatoires/chiffrés pour un déni plausible.
• Chiffrement à verrou temporel (optionnel) : dérivation de clé lente hors ligne basée sur une preuve de travail pour retarder le déchiffrement (anti-coercition).
• Chiffrement authentifié robuste : entièrement engageant, quantique-sûr ChaCha20-BLAKE2b AEAD.
• Étirement de clé fort : Argon2id (profil « sensitive » de libsodium) — 1 Gio de mémoire, 1 voie, 4 passes (par défaut et minimum).
• Matériel de clé arbitraire : dériver les clés à partir de phrases de passe, fichiers, périphériques en mode bloc ou répertoires — l’ordre n’a pas d’importance.
• CLI basée sur des invites : intuitive et interactive, aucun drapeau à mémoriser.
• [TODO] Format stable et documenté : prévu pour l’archivage à long terme et l’interopérabilité.

Utilisation

Vous n’avez pas besoin de mémoriser les options de ligne de commande pour utiliser tird. Cet outil dispose d’une CLI basée sur des invites : lancez-le simplement, sélectionnez une option du menu et répondez aux questions qui suivront.``` $ tird

                   MENU
———————————————————————————————————————————
0. Exit              1. Info & Warnings
2. Encrypt           3. Decrypt
4. Embed             5. Extract
6. Encrypt & Embed   7. Extract & Decrypt
8. Create w/ Random  9. Overwrite w/ Random
———————————————————————————————————————————

A0. SELECT AN OPTION [0-9]:

## Options d'entrée

Il y a 4 groupes d'options d'entrée : A (Action), D (Data), K (Keys), P (Proceed). Ils sont numérotés pour faciliter la description.```
+——————————————————————+————————————————————————+
| A0. SELECT AN OPTION | A. Select an action    |
+——————————————————————+————————————————————————+
| D1. INPUT FILE PATH  |                        |
| D2. COMMENTS         | D. Enter data,         |
| D3. OUTPUT FILE PATH |    data location,      |
| D4. OUTPUT FILE SIZE |    data size           |
| D5. START POSITION   |                        |
| D6. END POSITION     |                        |
+——————————————————————+————————————————————————+
| K1. KEYFILE PATH     | K. Enter values        |
| K2. PASSPHRASE       |    related to          |
| K3. TIME COST        |    key derivation      |
+——————————————————————+————————————————————————+
| P0. PROCEED?         | P. Confirm to continue |
+——————————————————————+————————————————————————+

Une description détaillée de ces options avec des exemples se trouve ici.

Charge utile

La charge utile qui sera chiffrée lors de la création du cryptoblob se compose de :

• Contenu d'un fichier (optionnel) : Un fichier ordinaire ou un périphérique bloc (disque/partition entier). Si omis, une charge utile de fichier vide est chiffrée.
• Commentaires (optionnel) : Chaîne UTF‑8 arbitraire, jusqu'à 1 Kio. Par défaut, le nom du fichier d'entrée est utilisé. Les commentaires déchiffrés sont affichés lors du déchiffrement.

La spécification de la charge utile dans l'interface utilisateur se présente comme suit :``` D1. FILE TO ENCRYPT (OPT): files.zip I: path: 'files.zip'; size: 2,824,230,648 B (2.6 GiB) D2. COMMENTS (DEFAULT='files.zip'): The X-Files, zip (секретные материалы) I: comments will be shown as ['The X-Files, zip (секретные материалы)']

## Matériau de clé d'entrée

`tird` offre la possibilité d'utiliser le contenu de fichiers de clés et une phrase de passe pour dériver des clés uniques.

- **Fichiers de clés (optionnel) :** Zéro, un ou plusieurs chemins de fichiers de clés ; l'ordre des entrées n'a pas d'importance. Un chemin de fichier de clé peut être :
  - Un <ins>fichier régulier</ins>. Le contenu du fichier de clé sera haché, et son condensat sera utilisé pour un étirement de clé et une dérivation de clé supplémentaires.
  - Un <ins>périphérique bloc</ins>. Traité de la même manière qu'un fichier de clé régulier : le contenu sera haché.
  - Un <ins>répertoire</ins>. Tous les fichiers du répertoire seront hachés et utilisés comme fichiers de clés.
- **Phrase de passe (optionnel) :** Jusqu'à 2048 octets après [normalisation](https://www.unicode.org/reports/tr15/) Unicode (forme C) ; peut être omise.

La spécification de l'IKM dans l'interface utilisateur ressemble à ceci :```
K1. KEYFILE PATH (OPT): key 
    I: path: 'key'; size: 32 B
    I: reading and hashing contents of 'key'
    I: keyfile accepted
K1. KEYFILE PATH (OPT): 
K2. PASSPHRASE (OPT): 
K2. CONFIRM PASSPHRASE: 
    I: passphrase accepted

Format des données chiffrées

• Format PURB :
  • Données qui semblent aléatoires et ne contiennent aucun en‑tête identifiable ; elles ne peuvent pas être distinguées de données aléatoires sans les clés correspondantes. Cette propriété permet de cacher les cryptoblobs parmi d’autres données aléatoires.
  • Taille aléatoire : la longueur du bourrage est choisie uniformément entre 0 % et 25 % de la taille du cryptoblob non rembourré (soit jusqu’à 20 % de la taille finale du cryptoblob).
• Commentaires : ils sont remplis (ou tronqués) à une taille fixe de 1 Kio avant le chiffrement, masquant complètement leur longueur d’origine.
• Sels appliqués bilatéralement : écraser le début ou la fin du cryptoblob (ou stocker un cryptoblob incomplet) rend le déchiffrement impossible.

Pour plus de détails, reportez-vous à la spécification.

Faible observabilité et minimisation des métadonnées

Tandis que le contenu d'un message chiffré est protégé, sa taille, sa provenance, sa destination… ne le sont pas. Les données sont cachées, les métadonnées sont visibles. Parfois, cela suffit à votre ennemi pour découvrir vos secrets.

— Loup Vaillant

Nous tuons des gens sur la base de métadonnées.

— Michael Hayden

vs.

• Format PURB :
  • Les fichiers chiffrés ressemblent à des données aléatoires.
  • Les fichiers chiffrés ont une taille aléatoire : ils ne révèlent pas la taille de la charge utile.
  • Les commentaires sont à bourrage constant, ils ne révèlent ni leur taille ni leur existence.
  • Ne prouve pas que les clés saisies sont incorrectes.
  • Interface en ligne de commande basée sur des invites : aucune fuite des options utilisées via l'historique du shell.
  • Le chemin du fichier de sortie est défini par l'utilisateur et n'est pas lié au chemin du fichier d'entrée par défaut.
  • Optionnel : masquer les données chiffrées dans des conteneurs.

tirdFS — Système de fichiers stéganographique piloté par l'utilisateur

tird utilise une technique qui est décrite comme suit :

Dissimulation de données dans des données chiffrées ou dans des données aléatoires. Le message à cacher est chiffré, puis utilisé pour écraser une partie d'un bloc beaucoup plus grand de données chiffrées ou d'un bloc de données aléatoires (un chiffre incassable comme le masque jetable génère des textes chiffrés qui semblent parfaitement aléatoires sans la clé privée).

Vous pouvez chiffrer des fichiers et intégrer des cryptoblobs dans des conteneurs à partir de positions arbitraires. Après avoir écrit le cryptoblob, vous devrez vous souvenir de son emplacement dans le conteneur (les positions de début et de fin), qui sera utilisé ultérieurement pour extraire les cryptoblobs. Ainsi, vous pouvez créer tirdFS — un système de fichiers caché, sans en‑tête et piloté par l'utilisateur à l'intérieur d'un conteneur :

• Il est caché car il est impossible de distinguer les données aléatoires du conteneur des données du cryptoblob, ainsi que de déterminer l'emplacement des cryptoblobs écrits sans connaître les positions et les clés.
• Il est sans en‑tête car les conteneurs ne contiennent aucun en‑tête ; toutes les données concernant les emplacements des cryptoblobs doivent être stockées séparément par l'utilisateur.
• La position de départ du cryptoblob dans le conteneur est définie par l'utilisateur, et l'utilisateur doit stocker à la fois les positions de début et de fin séparément du conteneur. C'est pourquoi il est appelé un système de fichiers piloté par l'utilisateur.

tirdFS n'est pas un système de fichiers monté avec des structures de métadonnées internes. C'est un modèle de stockage caché géré par l'utilisateur construit à partir de cryptoblobs placés indépendamment.

Tout fichier, disque ou partition plus grand que la taille minimale d'un cryptoblob (1160 B) peut être un conteneur valide. Les cryptoblobs peuvent être intégrés dans n'importe quelle zone.

Exemples de conteneurs valides :

1. Fichiers spécialement générés avec des données aléatoires.
2. Zones de disque contenant des données aléatoires. Par exemple, vous pouvez écraser un disque avec des données aléatoires, le formater en FAT32 ou exFAT, et utiliser une grande partie du disque, en laissant quelques dizaines de Mo depuis le début. Le disque semblera vide sauf si vous y ajoutez quelques fichiers.
3. Volumes chiffrés LUKS.
4. Conteneurs VeraCrypt, même ceux qui contiennent déjà des volumes cachés.

Exemple de structure de conteneur :``` +—————————+—————————————+ <— Position 0 of the container | | | | | Random data | | | | | +—————————————+ <— Cryptoblob1 start position | Header- | | | less | Cryptoblob1 | | | | | Layer +—————————————+ <— Cryptoblob1 end position | | Random data | | Cake +—————————————+ <— Cryptoblob2 start position | | | | | Cryptoblob2 | | | | | +—————————————+ <— Cryptoblob2 end position | | Random data | +—————————+—————————————+

**Header géré par l'utilisateur**

Un en-tête texte `tirdFS` géré séparément par l'utilisateur pourrait ressembler à ceci :```
[100000000:100345765] secret_video.mp4
[100345765:234765345] various_secrets.zip
[12654876456:14765345098] Epstein_files_part1.zip

C'est-à-dire qu'il doit généralement contenir l'emplacement de chaque cryptoblob dans le conteneur ainsi qu'un bref commentaire. Cependant, l'utilisateur est libre de déterminer comment stocker les positions et quoi inclure dans un tel en-tête.

Visualisation de l'incorporation

L'image suivante visualise à quel point il est difficile de distinguer une entrée de données aléatoires d'une autre et le processus d'incorporation de cryptoblobs dans un conteneur.

Stocker et transporter des données cryptées dissimulées

Transportez partout. C'est votre droit.

— Kyle Rittenhouse

Veuillez regarder la capture d'écran suivante.

Il semble que ce volume de 16 Go ne contienne qu'un seul fichier de 8,7 Mio. Est-ce vraiment vrai ? Peut-être oui, peut-être non.

Le système de fichiers nous indique qu'il n'y a qu'un seul fichier ici. Mais n'y a-t-il vraiment qu'un seul fichier sur le volume ? Nous ne pouvons pas le déterminer en utilisant le système de fichiers. En fait, des données peuvent se trouver en dehors du système de fichiers et être indétectables par les outils du système de fichiers. Les 15,2 Gio d'espace marqués comme libres peuvent être occupés par un système de fichiers caché. Cet espace « libre » peut être occupé par des données cryptées dissimulées.

Pouvons-nous réfuter l'existence de ces données ? Oui, par exemple en examinant le niveau d'entropie de cet espace libre à l'aide de binwalk. Une faible entropie indique une probable absence de données cachées. Une entropie élevée ne prouve pas, en soi, la présence de données cryptées dissimulées. Les zones à haute entropie peuvent être soit simplement des données résiduelles, soit des données cryptées dissimulées.

Si vous êtes intéressé par la dissimulation de données en dehors du système de fichiers visible, alors tird est à votre service pour fournir une Cape d'Invisibilité pour vos fichiers.

Chiffrement à verrou temporel

Le chiffrement à verrou temporel (TLE) peut être utilisé pour empêcher un adversaire d'accéder rapidement aux textes en clair en cas de compromission de l'IKM (par exemple en cas de coercition de l'utilisateur). Dans notre implémentation, il s'agit en fait d'une dérivation de clé à verrou temporel basée sur PoW. L'option d'entrée « Time cost » spécifie le nombre de passes d'Argon2. Si vous spécifiez un nombre de passes suffisamment élevé, il faudra un temps significatif pour les exécuter. Cependant, un attaquant nécessera le même temps en utilisant un matériel similaire. L'exécution d'Argon2 ne peut pas être accélérée par parallélisation, donc on s'attend à ce que le temps passé par un attaquant soit approximativement le même que celui passé par le défenseur.

Cette implémentation TLE fonctionne hors ligne, contrairement à tlock.

Définissez la valeur TIME COST souhaitée :``` K3. TIME COST (DEFAULT=4): 1000000 I: time cost: 1,000,000 W: decryption will require the same "TIME COST" value!

**Plausible TLE:** L'adversaire ne connaît pas la valeur réelle du coût de temps, donc vous pouvez plausiblement déformer le nombre de passages. L'adversaire ne peut pas réfuter votre affirmation jusqu'à ce qu'il tente de déchiffrer le cryptoblob en utilisant la valeur de coût de temps spécifiée.

## Options de ligne de commande

`tird` ne nécessite aucune option de ligne de commande pour une utilisation normale.```
$ tird --help
tird v0.30.0
        A tool for encrypting files and hiding encrypted data.
        Homepage: https://github.com/hakavlad/tird

Usage:
    tird [--unsafe-debug] [--unsafe-decrypt]

    Start without options for normal usage.

Options:
    --help            print this help message and exit
    --unsafe-debug    enable unsafe debug mode
    --unsafe-decrypt  release plaintext even if MAC verification
                      failed (dangerous)

Examples:
    $ tird
    $ tird --unsafe-debug

Mode de débogage non sécurisé

[!WARNING] Le mode de débogage n'est pas destiné à être utilisé en production !

Démarrez tird avec l'option --unsafe-debug pour voir ce qui se passe sous le capot pendant l'exécution du programme.

L'activation du mode débogage affiche également :

• Opérations sur les fichiers :
  • Ouverture et fermeture des descripteurs de fichiers.
  • Chemins réels des fichiers ouverts.
  • Déplacement des pointeurs de fichiers.
• Chaînes d'octets liées aux opérations cryptographiques : sels, phrases de passe, condensats, clés, nonces et étiquettes.
• Certaines autres informations, y compris diverses tailles.

Mode de déchiffrement non sécurisé

[!WARNING] Dans ce mode, le texte clair renvoyé peut avoir été modifié ou substitué par un attaquant !

En mode de déchiffrement non sécurisé, tird libérera le texte clair même si l'authentification échoue. À n'utiliser que si vous privilégiez la disponibilité à l'intégrité, lorsque vous ne pouvez pas déchiffrer avec succès un cryptoblob en mode normal.

Compromis et limitations

• tird ne prend pas en charge :
  • Cryptographie à clé publique.
  • Compression de fichiers.
  • Sortie en armure ASCII.
  • Correction d'erreur Reed–Solomon.
  • Division de la sortie en morceaux.
  • Utilisation des flux standard pour le traitement des fichiers (non destiné aux scripts automatisés).
  • Lecture et écriture de périphériques bloc de bas niveau sur MS Windows. Par conséquent, ces périphériques ne peuvent pas être utilisés comme fichiers de clé, ne peuvent pas être écrasés, et ne peuvent pas être chiffrés ou incorporés.
• tird ne fournit pas :
  • Une interface graphique.
  • Un générateur de mots de passe.
• tird ne peut pas traiter (chiffrer/incorporer) plus d'un fichier en une seule passe. Le chiffrement de répertoires et de fichiers multiples n'est pas pris en charge.
• tird ne nettoie pas les métadonnées du système de fichiers (atime, mtime, ctime).
• La vitesse de chiffrement de tird n'est pas très élevée (jusqu'à 730 Mio/s dans mes tests sur du matériel moderne).

Avertissements

La crypto peut aider, mais elle ne vous sauvera pas des mauvais usages, des vulnérabilités, de l'ingénierie sociale ou des menaces physiques.

— Loup Vaillant

• ⚠️ L'auteur n'a pas de formation en cryptographie.
• ⚠️ Le code n'a pas de couverture de tests automatisés.
• ⚠️ tird n'a pas été audité indépendamment par des humains en matière de sécurité.
• ⚠️ tird est inefficace dans un environnement compromis ; l'exécuter dans de tels cas peut provoquer des fuites de données désastreuses.
• ⚠️ tird a peu de chances d'être efficace lorsqu'il est utilisé avec des clés courtes et prévisibles.
• ⚠️ tird n'efface pas ses données sensibles de la mémoire après utilisation ; les clés peuvent persister en mémoire après la sortie du programme.
• ⚠️ Les données sensibles peuvent fuir dans l'espace d'échange.
• ⚠️ Les horodatages du système de fichiers ne sont pas nettoyés — peuvent fuir des métadonnées opérationnelles.
• ⚠️ tird ne trie pas les condensats des fichiers de clé et des phrases de passe en temps constant.
• ⚠️ Écraser le contenu des fichiers ne garantit pas la destruction sécurisée des données sur le support.
• ⚠️ Vous ne pouvez pas prouver à un adversaire que vos données aléatoires ne contiennent pas d'informations chiffrées.
• ⚠️ tird protège les données, pas l'utilisateur ; il ne peut pas empêcher la torture si vous êtes suspecté.
• ⚠️ La dérivation de clé consomme 1 Gio de RAM, ce qui peut entraîner des problèmes de performance ou des plantages sur les systèmes à faible mémoire.
• ⚠️ Intégrité/authenticité plutôt que disponibilité — modifier ne serait-ce qu'un seul octet d'un cryptoblob empêche le déchiffrement.
• ⚠️ Le développement n'est pas terminé, et il peut y avoir des problèmes de compatibilité ascendante.

Prérequis

• Python >= 3.9.2
• cryptography >= 2.1 (fournit HKDF et une implémentation rapide de ChaCha20)
• PyNaCl >= 1.2.0 (fournit des implémentations rapides de Argon2 et BLAKE2)
• colorama >= 0.4.6 (spécifique à Windows)

Documentation

• 📜 Page de manuel tird(1)
• 📑 Spécification
• 📄 Options d'entrée
• 📖 Tutoriel/Démo
• ❓ FAQ/Justification
• 📥 Installation

À faire

Améliorer la documentation.

Retours d'information

N'hésitez pas à poser des questions, laisser des commentaires ou fournir des critiques dans la section Discussions.