FarewellArchitecture de sécurité · dernière mise à jour le 16 juin 2026
Comment Farewell protège vos données, précisément.
Voici les algorithmes, paramètres et le format sur disque exacts qu'utilise Farewell.
Principes de conception
- Uniquement des primitives standard. Aucune cryptographie maison — AES-GCM-SIV, Argon2id, BLAKE3, Ed25519, ML-DSA-87, toutes issues d'implémentations soigneusement revues.
- Hors ligne par construction. L'application n'ouvre aucune socket — aucun compte, aucune synchronisation, aucune télémétrie. Rien à intercepter, rien à réquisitionner sur un serveur.
- Aucune récupération, aucune porte dérobée. La phrase secrète (et la clé matérielle optionnelle) est le seul moyen d'entrer. Nous ne pouvons pas la réinitialiser, et personne ne peut nous y contraindre.
- Hormis le sel aléatoire, chaque octet restant est, sans la bonne phrase secrète, indistinguable de données aléatoires sur le plan calculatoire. Un fichier de coffre ne contient en clair aucun nombre magique, version ni identifiant d'algorithme. Le seul texte en clair est un sel aléatoire de 32 octets.
Chiffrement au repos
Tout le contenu du coffre est scellé avec AES-256-GCM-SIV, un chiffrement authentifié (AEAD). GCM-SIV est préféré à l'AES-GCM simple pour sa résistance à la réutilisation de nonce : même si un nonce venait à être réutilisé, cela ne divulgue pas catastrophiquement la clé ni les relations entre textes clairs comme le ferait GCM.
| Chiffrement | AES-256-GCM-SIV (RFC 8452) |
| Taille de clé | 256 bits |
| Nonce | 96 bits (12 octets) |
| Étiquette d'authentification | 128 bits (16 octets) |
| Données associées | liées à chaque enregistrement (liées à la position, empêchent le réordonnancement) |
Le contenu des fichiers est découpé en blocs de 64 Kio ; chaque bloc est chiffré indépendamment avec sa propre clé dérivée de la clé maîtresse via BLAKE3, de sorte qu'un accès aléatoire ne nécessite jamais de déchiffrer tout le coffre et que les blocs ne peuvent pas être échangés entre positions.
Dérivation de clé (phrase secrète)
Votre phrase secrète est étirée en une clé avec Argon2id — la KDF à coût mémoire recommandée pour le hachage de mots de passe — ce qui rend les attaques par devinette hors ligne ruineusement coûteuses.
| Algorithme | Argon2id, version 1.3 (0x13) |
| Coût mémoire | 1 Gio (1 048 576 Kio) |
| Itérations (t) | 4 |
| Parallélisme (p) | 4 voies |
| Sortie | 32 octets (clé de 256 bits) |
| Sel | 32 octets aléatoires, uniques par coffre |
| Coût | ≈ 2 s sur Apple Silicon (M2) |
Les coffres à clé matérielle utilisent volontairement une KDF plus légère. Quand un coffre est lié à une clé FIDO2, c'est le secret matériel de la clé — et non la phrase secrète — qui porte la résistance au forçage brut : un fichier copié est alors incassable sans la clé physique, quel que soit le coût de la KDF. Le profil choisi n'est pas stocké sur le disque (ce serait une empreinte) ; à l'ouverture, Farewell essaie simplement les candidats dans l'ordre.
Hachage & sous-clés
BLAKE3 (256 bits) est utilisé pour le hachage d'intégrité, comme MAC à clé, et pour dériver les sous-clés par bloc à partir de la clé maîtresse via son mécanisme de contexte derive_key.
Posture post-quantique
Votre contenu est protégé par une clé symétrique de 256 bits, qui reste très au-delà de la portée des attaques quantiques prévisibles. Il est scellé avec AES-256-GCM-SIV (256 bits) ; la meilleure attaque quantique connue (Grover) ne la ramène qu'à ~128 bits de sécurité effective — hors de portée. Et comme un coffre local se déverrouille symétriquement à partir de votre phrase secrète (sans étape à clé publique), il n'y a rien que l'algorithme de Shor puisse attaquer.
L'attestation d'intégrité survit indépendamment de votre phrase secrète, mais pas la clé de signature.
Pour une défense en profondeur, chaque coffre est estampillé à la création par une signature ML-DSA-87 à usage unique (NIST FIPS 204, le standard de signature post-quantique) sur ses métadonnées fixes (version du format, capacité, sel et clé de vérification).
« Où est la clé de signature privée ? » Nulle part — par conception. La clé de signature est éphémère : une paire de clés fraîche est générée à la création, utilisée une seule fois pour signer, puis la clé secrète est effacée de la mémoire immédiatement. Elle n'est jamais écrite sur le disque, jamais réutilisée, et ne subsiste nulle part ensuite — il n'y a aucune clé de signature à voler, à fuiter ou que l'on pourrait nous contraindre à produire. Seules la clé de vérification (publique par nature) et la signature subsistent, et elles vivent à l'intérieur des métadonnées chiffrées par l'AEAD.
La confidentialité et l'authenticité du coffre reposent sur l'AEAD plus votre phrase secrète ou clé matérielle : les métadonnées ne peuvent être lues ni modifiées sans elles. L'estampille ML-DSA-87 vient par-dessus, en tant que contrôle d'intégrité indépendant et diversifié sur le plan algorithmique, et fournit une empreinte stable par coffre (un hachage de la clé de vérification) que vous pouvez enregistrer et revérifier.
« Si la clé de vérification est livrée dans le blob même qu'elle signe, à quoi sert la signature ? » Une fois qu'un attaquant possède la clé du coffre, la confidentialité et l'intégrité sont déjà compromises ; la signature n'est pas censée défendre contre ce scénario, nous ne prétendons donc pas qu'elle ajoute une authenticité vis-à-vis de tiers (c'est l'AEAD + votre phrase secrète qui le font). Sa valeur honnête est plus étroite et triple : (1) la diversité algorithmique — un contrôle post-quantique indépendant sur les métadonnées qui détecterait une faille de la chaîne AES-GCM-SIV que l'étiquette GCM elle-même aurait manquée ; (2) une empreinte stable et vérifiable du coffre ; (3) un emplacement compatible avec l'avenir — le même champ est conçu pour accueillir un signataire non éphémère (une clé liée à une release ou à un appareil) dans une version ultérieure, ce qui ajouterait une authenticité vis-à-vis de tiers, sans rupture de format. La forme éphémère d'aujourd'hui est cette mécanique dans son cas le plus simple.
| Chiffrement du contenu | AES-256-GCM-SIV — 256 bits, résistant à Grover |
| Signature d'intégrité | ML-DSA-87 (FIPS 204), à usage unique par coffre |
| Clé de signature | éphémère — générée à la création, puis détruite |
| Clé de vérification / signature | 2592 o / 4627 o (stockées dans les métadonnées chiffrées) |
| Implémentation | libcrux (formellement vérifiée) |
Format du coffre (v6)
Un coffre est un fichier unique à disposition fixe. Hormis le sel aléatoire de tête, chaque octet est du texte chiffré ou du remplissage aléatoire — il n'y a aucun en-tête ni marqueur qui l'identifierait comme un coffre Farewell.
# disposition sur disque — rien en clair sauf le sel
[0 .. 32) sel 32 octets, aléatoire uniforme (en clair)
[32 .. 4128) slot 4096 octets — clé maîtresse emballée (AEAD),
ou remplissage aléatoire (déni plausible)
[4128 .. +blob) métadonnées blob AEAD : nombre de blocs + l'attestation
ML-DSA-87 à usage unique
[.. .. EOF) blocs 64 Kio de texte clair chacun, stockés en
nonce 12 o + texte chiffré + 4 + étiquette 16 o
| Version du format | v6 (0x0006) — non écrite en clair |
| Clé maîtresse | 256 bits, emballée (AEAD) dans le slot |
| Clés matérielles | jusqu'à 3 clés FIDO2 par coffre (n'importe laquelle l'ouvre) |
| Texte clair par bloc | 65 536 octets (64 Kio) |
| Effacement automatique | aucun — voir ci-dessous |
Il n'y a délibérément aucune fonction d'« effacement après N échecs » : un compteur mis à jour à chaque mauvaise phrase secrète devrait vivre en dehors du chiffrement gardé par la phrase secrète, rendant le fichier détectable — incompatible avec le déni au niveau de l'octet, et inutile face à un adversaire qui a d'abord imagé le disque. La résistance aux devinettes hors ligne repose plutôt sur Argon2id + l'entropie de la phrase secrète (et la clé matérielle optionnelle).
Hygiène des clés en mémoire
Les clés n'existent en RAM que pendant qu'un coffre est ouvert. Farewell borne et nettoie cette exposition avec les défenses standard — et est honnête sur la limite au-delà de laquelle aucun programme en espace utilisateur ne peut aller.
| Clé maîtresse active | conservée dans un tampon épinglé par mlock (SecureBuffer) |
| Anti-swap | mlock(2) — les pages de clé ne sont pas écrites en swap (au mieux) |
| Au verrouillage / à la libération | mise à zéro : clé maîtresse, clés dérivées, clés AEAD |
| Secrets transitoires | phrase secrète & clés d'emballage effacées immédiatement après usage |
| Primitive d'effacement | crate zeroize — écritures volatiles + barrière du compilateur |
« Comment vérifiez-vous que l'effacement est effectif ? » La partie qui peut être garantie l'est au niveau du compilateur : la crate zeroize écrase les secrets par des écritures volatiles plus une barrière du compilateur, de sorte que l'optimiseur ne peut pas discrètement supprimer la mise à zéro comme il le peut avec un memset naïf sur une mémoire sur le point d'être libérée. Cette crate est largement utilisée et auditée, et vous pouvez le confirmer en lisant le code source. Les clés sont aussi mlockées, afin de ne jamais atteindre le swap où elles survivraient au processus. Ce qu'aucun programme en espace utilisateur ne peut pleinement garantir, c'est le reste de la machine — une image de veille prolongée, des copies de pages par le noyau, les registres du CPU et les débordements de pile, ou la phrase secrète lorsqu'elle transite brièvement par le champ texte de l'OS et la pile USB. Nous atténuons (mlock contre le swap, mise à zéro à la libération, verrouillage automatique pour réduire la fenêtre) et nous divulguons la limite plutôt que de revendiquer une perfection que personne ne peut offrir.
Et nous le testons, en CI. Un test de non-régression initialise un tampon de clé avec une sentinelle connue, le libère, et vérifie que la zone mémoire sous-jacente est ensuite entièrement à zéro. Pour le faire de façon saine — lire de la mémoire libérée serait en soi un comportement indéfini — l'instantané est pris depuis l'intérieur du dealloc de l'allocateur, tant que la mémoire est encore vivante, et il surveille une allocation précise plutôt que de balayer tout le tas (donc aucun faux positif dû à des copies transitoires). Retirer l'effacement fait échouer le test immédiatement, de sorte qu'un changement futur ne peut pas le supprimer en silence. Cela protège la partie réellement à risque — une copie de clé s'échappant du tampon, ou un effacement manquant — pas les limites au niveau de l'OS ci-dessus, qu'aucun test ne peut atteindre.
Ce que Farewell ne fait délibérément pas
- Aucune connexion réseau d'aucune sorte — pas de télémétrie, pas de serveur de licence, pas de « phone home ».
- Aucune récupération de phrase secrète, clé maîtresse ni séquestre.
- Aucune métadonnée, nom de fichier ni taille en clair divulgués sur le disque.
- Aucune copie déchiffrée écrite sur le disque pendant que vous consultez des fichiers.
Modèle de menace
Le chiffrement n'est utile que face aux menaces qu'il traite réellement. Voici le périmètre honnête — ce que Farewell est conçu pour déjouer, et ce qu'il ne peut pas.
Ce qu'il protège
- Les données au repos. Un coffre verrouillé est inintelligible sans votre phrase secrète (et la clé matérielle, si vous en avez configuré une).
- Le vol ou la saisie hors ligne du fichier. Un ordinateur portable volé, un disque imagé, une clé USB copiée, une sauvegarde cloud du coffre — tous inutiles pour qui les détient.
- L'altération. Toute modification du fichier est détectée à l'ouverture (authentification AEAD).
- « Récolter maintenant, déchiffrer plus tard ». Le contenu est scellé avec une clé symétrique de 256 bits, hors de portée de toute attaque quantique prévisible.
- La divulgation forcée venant de nous. Il n'y a aucune clé de récupération, aucun serveur, aucune porte dérobée — rien qu'on puisse nous forcer à remettre.
Ce qu'il ne protège pas
- Un coffre déverrouillé. Une fois ouvert, son contenu est en clair pour cette session — quiconque est devant votre machine déverrouillée voit ce que vous voyez.
- Un logiciel malveillant exécuté sous votre compte. Du code disposant de vos privilèges peut lire ce que vous pouvez lire ; le chiffrement ne peut pas se barricader contre votre propre utilisateur.
- La capture d'écran et les enregistreurs de frappe. Un OS, un clavier ou un enregistreur d'écran compromis capture votre phrase secrète et votre texte clair pendant que vous les tapez et les consultez.
- Une machine compromise pendant son utilisation. mlock et zeroize relèvent la barre contre la forensique par cold-boot et swap, mais un système vivant et rooté est hors périmètre.
- La contrainte exercée sur vous. Farewell vous aide à éviter de révéler qu'un coffre existe ; c'est une atténuation, pas une garantie face à un adversaire capable de vous contraindre.
En résumé : Farewell protège le fichier, pas la machine en cours d'utilisation. Gardez le coffre verrouillé quand vous ne l'utilisez pas, et exécutez-le sur un appareil de confiance.
Des questions, ou envie de scruter la cryptographie ? Écrivez à security@farewell.pro.