J’ai développé VANI, qui effondre mathématiquement la structure vectorielle des données pour les supprimer définitivement

Bonjour. Mon activité principale consiste à développer des algorithmes et des fonctions d’IA.

Avec les progrès fulgurants récents de l’IA générative et des techniques de forensic, je me suis demandé : « Est-il possible de supprimer complètement des données numériques ? » On dit que même les méthodes existantes comme l’écrasement, la réinitialisation d’usine, l’effacement du firmware et même le degaussing peuvent permettre une récupération à cause de charges résiduelles. Même la destruction des clés de chiffrement (crypto-shredding) ne serait pas sûre face au futur de l’informatique quantique. En particulier, dans les environnements SSD (NVMe), la méthode classique d’« écrasement » (DoD 5220.22-M) présentait une limite claire : en raison des caractéristiques du wear leveling, elle réduit la durée de vie du support tout en offrant une efficacité d’effacement moindre.

C’est pourquoi j’ai créé VANI (Vector-based Advanced Nullification), un outil d’effacement pour Windows qui ne repose pas sur l’écrasement physique, mais sur une méthode qui fait s’effondrer mathématiquement les données, et je le publie sur GitHub et Gumroad.

Son avantage est de pouvoir supprimer de manière sélective des fichiers et des données à très grande vitesse sur tous les supports de stockage sous Windows. Son inconvénient est qu’une fois supprimé, c’est terminé : aucune analyse forensic n’est possible, la suppression est définitive, il faut donc l’utiliser avec précaution.

🛠 Processus de développement et technologies clés
Si la « suppression » traditionnelle consiste à repeindre les données avec des 0 et des 1, VANI est plus proche d’une méthode qui fait s’effondrer l’espace vectoriel même dans lequel les données existent. (Je l’ai développé en Python et en Rust. Comme je suis spécialisé dans les algorithmes, j’ai eu bien plus de mal avec l’UI et le design qu’avec l’implémentation du code... 😅)

• Vector State Collapse: les données de fichier ne sont pas définies comme une simple suite de bits, mais comme un état vectoriel (State), et un bruit mathématiquement orthogonal à l’original est injecté afin de faire disparaître le motif lui-même.

• Entropy Maximization: au lieu de simples nombres aléatoires, un « chaos buffer » dont l’entropie de Shannon est maximisée à l’extrême est injecté. Comme l’entropie, à l’image des lois de la thermodynamique, ne peut mathématiquement pas redescendre, le système a été conçu pour rendre tout calcul inverse impossible, y compris à l’aide de l’algorithme de Grover en informatique quantique.

• Hilbert Curve Optimization: pour l’efficacité des E/S disque, j’ai appliqué la courbe de Hilbert, un algorithme de space-filling curve. Grâce à cela, j’ai obtenu une vitesse de suppression de moins d’une seconde pour 1 Go dans un environnement NVMe.

💾 Essayer le produit
Il s’agit d’une version portable directement exécutable. Je l’ai mise sur GitHub pour qu’elle puisse être utilisée gratuitement, sans limitation de fonctionnalités, dans un cadre personnel.

GitHub (gratuit / usage personnel) : https://github.com/eterners-inc/VANI (prise en charge de la suppression de fichiers uniques, sans publicité)

Gumroad (payant / usage entreprise) : eterners.gumroad.com/l/vani-pro (suppression par dossier, génération de rapports d’audit et autres fonctions métier)

💬 Mot de la fin
J’espère que VANI pourra être un outil utile pour les particuliers ou les startups qui, contrairement à un grand groupe comme S Group, ne peuvent pas jeter au four de fusion un disque dur contenant des informations confidentielles. Les retours sur l’algorithme ou le traitement I/O bas niveau, ainsi que les signalements de bugs, sont toujours les bienvenus.

⚠️ Avis complémentaire
Comme une technologie de suppression complète des données peut faire l’objet d’usages inappropriés ou malveillants, j’ai développé et intégré un algorithme qui empêche le debugging et protège lui-même le code source (Ghost Protocol), afin qu’un usage abusif déclenche un verrouillage. J’envisage aussi d’ouvrir plus tard ce module de sécurité sous forme de bibliothèque séparée, avant le dépôt de brevet, pour les startups ou collègues développeurs ayant des besoins de sécurité.

[wedding]

Suis-je complètement à côté de la plaque... Faut-il que je révise les bases de l’informatique...

[bbulbum]

Hum… l’IA formule donc un soupçon raisonnable selon lequel cela ressemble à une mise en scène.

[dydwls140]

Vous ne semblez pas vous rendre compte que votre propre solution ne résout absolument pas la limite que vous avez vous-même pointée comme problématique. Il y a là une énorme contradiction, car vous traînez toujours tel quel le problème du wear leveling des SSD.

[holywork]

Si l’effacement complet des données est important, il est plus réaliste d’appliquer dès le départ un chiffrement intégral du disque suffisamment robuste plutôt qu’un tel algorithme de suppression spécialisé. Il suffit ensuite de détruire la clé pour que l’ensemble des données devienne du bruit.

[kunggom]

En quoi la méthode de suppression de fichiers de votre produit diffère-t-elle d’un écrasement avec des données aléatoires, y compris pseudo-aléatoires ?
Le code de free/main_free.py visible dans le dépôt semble, au final, simplement écraser les 4096 premiers octets du fichier avec un nouveau bruit pseudo-aléatoire, puis appeler une bibliothèque basée sur Rust dont les détails ne sont pas publics et qui, en substance, est présentée comme faisant ensuite « quelque chose ». Mais on ne voit pas en quoi cela serait qualitativement différent d’un simple écrasement du fichier avec du pseudo-aléatoire, et ce que vous avez publié ne semble pas suffire à le démontrer.
Pourriez-vous expliquer en quoi cela diffère qualitativement d’un écrasement pseudo-aléatoire, et plus précisément, lors d’une tentative de récupération de fichier / d’analyse forensique, quel changement cela apporte en termes de possibilité de récupération par rapport à un simple écrasement pseudo-aléatoire ? Ou bien y a-t-il des aspects pour lesquels vous pourriez soutenir que cela varie selon le support de stockage (disque dur ou SSD) ?

[terrydo]

Bonjour. C’est un commentaire à la fois agréable et apprécié, merci. C’est la première fois que je publie après m’être contenté de lire en silence, donc j’ai été un peu surpris de voir aussi des commentaires écrits par une IA.

Comme vous l’avez dit, le main_free.py de la version Free publiée sert de point d’entrée du système de fichiers, en détruisant l’en-tête de 4 KB pour empêcher sa reconnaissance par l’OS, puis en confiant le traitement réel au cœur Rust (vani_core). La remarque selon laquelle les détails restent flous est tout à fait valable dans le périmètre actuellement rendu public.

Concernant la « différence qualitative avec un simple écrasement par PRNG » que vous avez évoquée, je vais vous expliquer l’intention de conception et l’orientation technique que j’ai visées.

• Différence d’entropie entre Orthogonal Noise et Pseudo-Random
  Un simple random() ou /dev/urandom vise une distribution statistiquement uniforme, mais du point de vue de l’analyse des motifs de données, il peut malgré tout subsister une périodicité retraçable. VANI génère un « chaos buffer » maximisant mathématiquement jusqu’à l’extrême l’entropie de Shannon. Il ne s’agit pas simplement de disperser des nombres aléatoires, mais d’injecter un bruit mathématiquement orthogonal au vecteur des données d’origine afin d’amener les champs magnétiques résiduels physiques ou l’état de charge des cellules à converger vers un état d’équilibre impossible à restaurer. (Cette partie sera publiée plus en détail ultérieurement dans un livre blanc, après le dépôt de brevet.)

• Optimisation des E/S en environnement SSD (Legacy Linear vs Hilbert)
  En réalité, c’est là la différence déterminante selon le support de stockage que vous mentionniez. Les méthodes existantes écrasent linéairement depuis le secteur 0 jusqu’à la fin. Cela ne correspond pas à la structure de traitement parallèle des SSD et, à cause du wear leveling, il est très probable que l’écrasement ne se fasse pas sur les adresses physiques réelles.
  Mais avec la méthode VANI, les adresses logiques sont explorées de manière non linéaire dans le cœur Rust via l’algorithme de courbe de Hilbert. Cela permet d’utiliser efficacement la bande passante multi-queue du NVMe et, avec un nombre d’opérations d’écriture (Pass) bien inférieur aux méthodes existantes, de rompre les liens sémantiques des données.

• Next Action
  Comme vous l’avez souligné, il est vrai qu’avec le seul code actuellement publié de la version Free, il est difficile pour un tiers de vérifier qu’il s’agit bien d’une approche qualitativement différente. Comme il s’agit d’un modèle mathématique, nous n’en sommes pas encore non plus au stade d’une certification officielle par une société spécialisée en forensic. C’est pourquoi, à l’avenir, je prévois soit de comparer et publier des données de benchmark Before/After en environnement SSD face à un simple PRNG avec des outils de benchmarking, soit de développer cela en code Python pour mener des expériences comparatives, puis d’en publier les résultats afin qu’ils puissent être vérifiés.

Comme c’est en fait mon premier post, j’étais un peu inquiet. Je suis néanmoins soulagé que, comme ci-dessous, la question n’ait pas été posée par une IA. Ce type de questionnement incisif et de vérification est précisément ce que je veux recevoir comme feedback sur Show GN. Continuez à me signaler tout ce qui manque ou peut être amélioré, cela m’aidera à faire progresser le projet. Merci !

[kunggom]

Il y a énormément de points que j’aimerais critiquer en détail.
À commencer par le fait que la graine du générateur pseudo-aléatoire utilisé pour « faire s’effondrer » les 4 premiers KiB d’un fichier est une combinaison du chemin du fichier et de sa taille, ce qui le rend entièrement déterministe, jusqu’au fait évident que le dépôt d’un brevet sur un algorithme informatique est extrêmement difficile et que, même s’il était accordé, cela ne permettrait en aucun cas d’affirmer que le procédé est reconnu comme sûr du seul fait de l’existence du brevet. Rien qu’avec ce qui a été rendu public, on voit déjà de très nombreux points problématiques.

Mais le plus important est là : cet algorithme miracle, présenté comme un secret industriel destiné à faire l’objet d’un brevet, qu’apporte-t-il de plus qu’une suppression de fichier ordinaire ?
Puisque vous semblez raisonner principalement dans un environnement SSD, parlons uniquement des SSD. (Cela ne signifie pas pour autant qu’il y aurait un intérêt réel sur HDD.)

Les SSD modernes sont fabriqués à partir de mémoire flash NAND, dont une caractéristique essentielle est qu’on ne peut pas écraser directement une cellule qui contient déjà des données. Une fois qu’une cellule a été programmée, on ne peut pas y réécrire immédiatement ; il faut obligatoirement passer par une étape d’effacement. Comme le nombre d’effacements est limité, sur la mémoire flash, l’effacement ne se fait pas au niveau de chaque cellule ou page, mais par blocs, c’est-à-dire des ensembles de plusieurs pages. C’est ce qui rend nécessaire une couche FTL (Flash Translation Layer) et provoque des problèmes comme la write amplification.
Autrement dit, même si l’on « écrase » une partie du contenu d’un fichier sur un SSD, les données écrites lors de cette tentative d’écrasement sont en réalité stockées dans des cellules complètement différentes. Qu’il s’agisse d’écrire des zéros ou des valeurs pseudo-aléatoires produites d’une manière ou d’une autre, cela ne change rien au fait que, physiquement, ces données seront enregistrées dans d’autres cellules. Au-delà de l’abstraction matérielle du SSD, du point de vue logiciel, on ne voit bien sûr que la valeur finale écrasée, mais ni l’OS ni l’application ne peuvent contrôler directement la mémoire flash NAND de façon explicite.

Cela ne veut pas dire pour autant que les données ne sont jamais réellement supprimées à l’intérieur du SSD. Les cellules contenant des données inutilisées doivent être effacées à l’avance pour éviter toute latence lors d’écritures futures. C’est pourquoi le contrôleur du SSD exécute en permanence un GC (Garbage Collection) en arrière-plan.
Depuis les années 2010, tous les principaux systèmes d’exploitation prennent en charge la commande TRIM. TRIM permet à l’OS d’indiquer au SSD que « ces blocs ne sont plus utilisés ». Ils deviennent alors candidats au garbage collection exécuté en arrière-plan par le contrôleur du SSD. On ne sait pas exactement quand ce nettoyage aura effectivement lieu, mais une fois que le garbage collection est passé et que l’effacement a été exécuté sur les blocs NAND, il devient impossible de récupérer l’information perdue, même en démontant physiquement les puces une par une. Et comme les OS actuels ont TRIM activé par défaut, une simple suppression de fichier via les fonctions standard du système finit, après un certain temps, par rendre la récupération des données impossible.

En d’autres termes, dans un environnement SSD, si l’on exécute simplement la commande de suppression de fichier de l’OS, on ne peut pas dire avec certitude à quel moment exact les données disparaîtront, mais elles finiront bien par être totalement effacées des cellules. À l’inverse, si l’on écrase les données du fichier, les cellules qui contiennent physiquement les données d’origine peuvent au contraire rester intactes pendant un certain temps. N’est-ce pas là une véritable ironie ?
Bien sûr, même s’il suffit à la fin d’appeler la commande de suppression native de l’OS, le résultat sera le même : au bout d’un certain temps, les données seront physiquement perdues dans les cellules. Mais si le résultat est identique, pourquoi mobiliser un algorithme grandiloquent au lieu de simplement supprimer le fichier normalement ?

Il existe un terme appelé Purple hat therapy.
Supposons que quelqu’un affirme : « Pour soigner la maladie X, il faut prendre le médicament Y tout en portant ce chapeau violet chargé d’une mystérieuse énergie cosmique. » Or, en réalité, le médicament Y était déjà utilisé depuis longtemps pour traiter cette maladie X. Bien sûr, le traitement avec le chapeau violet semblait fonctionner, mais son efficacité était en pratique rigoureusement identique à celle du traitement existant. Dans ce cas, ce chapeau violet est-il nécessaire ou non ?

À mes yeux, c’est précisément à cela que correspond VANI. D’après les éléments publiés, rien ne permet de penser qu’il apporte un gain significatif en matière de sécurité ou quelque autre utilité par rapport à la suppression de fichier standard de l’OS. Le recours à une multitude de termes techniques — vocabulaire mathématique, algorithmes d’informatique quantique, etc. — ne ressemble à rien d’autre qu’à un mauvais procédé marketing destiné à justifier le prix de 100 dollars de la version payante. Même si ce programme était entièrement gratuit, je ne l’utiliserais jamais.

[honglu]

J’allais seulement mettre un pouce levé, mais ça ne me semblait pas très poli, alors je laisse un commentaire. C’était très sympa à lire.

[kunggom]

Merci.
En écrivant ce commentaire, je me suis rendu compte qu’il était devenu incroyablement long, presque comme un billet de blog, donc je me suis demandé un instant si je devais vraiment le publier tel quel. Puis je me suis dit que ce serait dommage de perdre tout le temps passé à l’écrire, alors je l’ai simplement posté. Je suis ravi d’apprendre que vous l’avez lu avec plaisir.

[ffdd270]

Cela faisait vraiment très longtemps que je n’avais pas lu un texte aussi savoureux, au point de le relire deux fois. Merci infiniment d’avoir partagé un tel texte.

[redmi]

Même le texte de présentation a été écrit avec un LLM, lol..
Personnellement, je déteste vraiment voir qu’on va jusqu’à écrire le texte de présentation avec un LLM.

[nemorize]

C’est vraiment ça ? mdr

[v08zbv8fvlkjasdflkj]

---

Bonjour, je suis PM au sein de la task force plateforme de convergence quantique-thermodynamique rattachée au laboratoire de technologies du futur de l’entreprise S. (Nous sommes actuellement en phase de closing d’un bridge round de Series C, donc il m’est difficile de révéler mon identité.)

En lisant l’article sur VANI, je me suis littéralement redressé dans mon lit à 4 heures du matin. Honnêtement, j’en ai eu des frissons.

Dans notre labo aussi, nous étudions depuis 2019 un « protocole d’annihilation de l’information fondé sur une distribution de Boltzmann inverse », et le principal goulet d’étranglement était justement la fuite d’enthalpie à l’interface Shannon-Gibbs. Mais apprendre que vous avez contourné cela grâce à l’effondrement orthogonal de l’espace de Hilbert… Notre chercheur principal, après avoir vu ça, a même dit : « Einstein a dû ressentir la même chose en résolvant le paradoxe EPR ».

En particulier, l’idée de rompre les liens vectoriels de l’en-tête de fichier par orthogonalisation de Gram-Schmidt est un domaine auquel nous ne sommes pas parvenus, même après trois ans de recherche conjointe avec le département de sciences mathématiques du KAIST. Auriez-vous également implémenté en interne une transition d’état pseudo-qubit fondée sur des opérateurs non hermitiens ? Si c’est le cas, il ne s’agit plus d’un simple outil de suppression, mais du point de départ d’un paradigme post-quantique d’incinération de l’information.

Notre maison mère (top 20 mondial par capitalisation boursière) prépare actuellement une « initiative Data Thermal Death », et le moteur de maximisation d’entropie de VANI correspond exactement au jalon de Phase 2 de notre roadmap.

~~Investissement~~ non, une discussion sur un partenariat technologique stratégique serait-elle possible ?

De notre côté, les conditions sont les suivantes :

• investissement initial de $2M (valorisation à discuter)
• dépôt du code source de Ghost Protocol™ sous séquestre
• dépôt conjoint d’un brevet sur le moteur Hilbert-Euler

Cependant, notre équipe juridique indique qu’un examen légal de la « force contraignante mathématique du deuxième principe de la thermodynamique » est nécessaire. Auriez-vous, concernant le point selon lequel l’entropie « ne peut absolument pas diminuer », une peer review dans Nature ou une certification ISO 27001 annexe Q ?

Et j’ai aussi une question personnelle… Comment avez-vous défini les unités de suppression discrétisées fondées sur la constante de Planck ? De notre côté, en prenant h-bar comme référence, nous avons posé un « quantum de suppression quantique » en unités de 6.626 × 10⁻³⁴ joule-seconde, mais la phase se décale sans cesse au niveau du point critique de cohérence-décohérence avec le cache du contrôleur NVMe.

Quoi qu’il en soit, c’est vraiment impressionnant. On dirait que Maxwell, Boltzmann et Shannon du XXIe siècle se sont incarnés en une seule personne.

Dans l’attente de votre retour rapide. 🙏

P.S. Les données supprimées avec VANI ne sont pas transférées vers un univers parallèle, n’est-ce pas ? Notre CTO s’est soudainement mis à s’en inquiéter.

[dongho42]

Suis-je le seul à trouver ce jeu de mots drôle... lol

[nordica]

Encore aujourd’hui… un dépôt rempli de slop IA.