Desarrollé VANI, que colapsa matemáticamente la estructura vectorial de los datos para eliminarlos de forma permanente
(github.com/eterners-inc)Hola. Mi trabajo principal es el desarrollo de algoritmos y funciones de IA.
Últimamente, con el avance acelerado de la IA generativa y las tecnologías forenses, empecé a preguntarme: “¿Es posible eliminar por completo los datos digitales?”. Se dice que no solo la sobrescritura, el restablecimiento de fábrica y el borrado por firmware, sino incluso el degaussing pueden permitir recuperación debido a cargas residuales. El método de destrucción de claves de cifrado (Crypto-shredding) tampoco sería seguro frente a la computación cuántica del futuro. En particular, en entornos SSD (NVMe), por las características de Wear Leveling, el método tradicional de “sobrescritura (DoD 5220.22-M)” tiene limitaciones claras: acorta la vida útil y además reduce la eficiencia de borrado.
Por eso, en lugar de la sobrescritura física, creé VANI (Vector-based Advanced Nullification), una herramienta de borrado para Windows que colapsa matemáticamente los datos, y la publico en GitHub y Gumroad.
La ventaja es que permite seleccionar y borrar archivos y datos de forma ultrarrápida en cualquier dispositivo de almacenamiento basado en Windows; la desventaja es que, una vez borrado, se acabó: no hay posibilidad de análisis forense y la eliminación es permanente, así que debe usarse con cuidado.
🛠 Proceso de desarrollo y tecnología clave
Si el “borrado” tradicional es como pintar encima de los datos con 0 y 1, VANI se parece más a derrumbar el propio espacio vectorial donde existen los datos. (Lo desarrollé con Python y Rust. Como me especializo en algoritmos, creo que me costó mucho más el trabajo de UI/diseño que la implementación del código... 😅)
-
Vector State Collapse: define los datos del archivo no como una simple secuencia de bits, sino como un estado vectorial (State), e inyecta ruido matemáticamente ortogonal al original para extinguir el patrón mismo.
-
Entropy Maximization: inyecta un “chaos buffer” maximizado hasta el límite en términos de entropía de Shannon (Shannon Entropy), no simples números aleatorios. Como la entropía, al igual que las leyes de la termodinámica, no puede reducirse matemáticamente de nuevo, fue diseñado para que ni siquiera el algoritmo de Grover de la computación cuántica futura pueda revertirlo.
-
Hilbert Curve Optimization: para mejorar la eficiencia de I/O de disco, apliqué la curva de Hilbert, un algoritmo de space-filling curve. Gracias a eso, en entornos NVMe logré una velocidad de menos de 1 segundo para borrar 1GB.
💾 Pruébalo
Es una versión portable que se puede ejecutar de inmediato. La subí a GitHub para que pueda usarse gratis sin limitaciones funcionales para fines personales.
GitHub (gratis/uso personal): https://github.com/eterners-inc/VANI (soporta borrado de un solo archivo, sin anuncios)
Gumroad (de pago/uso empresarial): eterners.gumroad.com/l/vani-pro (borrado por carpetas, generación de reportes de auditoría y otras funciones de negocio)
💬 Comentario final
Espero que VANI pueda ser una herramienta útil para personas o startups que, a diferencia de grandes conglomerados, no pueden desechar en un horno de fundición discos duros con información confidencial. Siempre serán bienvenidos los comentarios sobre el algoritmo o el manejo de I/O de bajo nivel, así como los reportes de errores.
⚠️ Aviso adicional (Ghost Protocol) Como la tecnología de eliminación completa de datos puede prestarse a uso indebido o malicioso, desarrollé e integré un algoritmo de autodefensa del código (Ghost Protocol) para impedir la depuración y hacer que el sistema entre en lockdown ante un uso no autorizado. También estoy considerando abrir este módulo de seguridad más adelante como una biblioteca separada, antes de registrar la patente, para startups o colegas desarrolladores que necesiten seguridad.
15 comentarios
¿Seré yo el tonto...? ¿Necesito volver a estudiar Introducción a la Ingeniería en Computación...?
Mmm... la IA también está planteando una sospecha razonable de que parece una autopromoción montada.
No se da cuenta de que la limitación que usted mismo señaló como problema no queda resuelta en absoluto por su propia solución. Parece haber una enorme contradicción al seguir cargando exactamente con el problema del wear leveling de los SSD.
Si es importante borrar completamente los datos, es más realista aplicar desde el principio un cifrado de disco completo lo bastante fuerte, en lugar de usar este tipo de algoritmo de borrado especializado. Si solo se destruye la clave, todos los datos se convierten en ruido.
¿En qué se diferencia el método de eliminación de archivos de su producto de sobrescribirlos con datos aleatorios (incluidos seudoaleatorios)?
El código de
free/main_free.pyque puede revisarse en el repositorio, al final, parece limitarse a sobrescribir los primeros 4096 bytes del archivo con nuevo ruido seudoaleatorio y luego llamar a una biblioteca basada en Rust, no pública y de detalles desconocidos, afirmando que de algún modo hace algo más. Sin embargo, no queda claro en qué se diferencia cualitativamente esto de simplemente sobrescribir el archivo con seudoaleatoriedad, y con lo que han publicado no parece haber suficiente para demostrarlo.¿Podrían explicar en qué aspecto esto es cualitativamente distinto de una sobrescritura seudoaleatoria y, de forma concreta, qué cambio habría en términos de posibilidad de recuperación al intentar restaurar el archivo o hacer análisis forense, en comparación con simplemente sobrescribirlo con seudoaleatoriedad? ¿O hay algún punto que, según el medio de almacenamiento (disco duro o SSD), pueda sostenerse que cambia?
Hola. Es un comentario agradable y agradezco mucho que lo hayan dejado. Es la primera vez que publico algo después de solo leer en silencio, así que me tomó un poco por sorpresa ver también comentarios escritos por IA.
Como mencionaste, el
main_free.pyde la versión Free publicada funciona como punto de entrada del sistema de archivos, bloqueando el reconocimiento por parte del SO al colapsar el encabezado de 4 KB, y luego delega el procesamiento real al núcleo en Rust (vani_core). La observación de que faltan detalles es totalmente válida dentro del alcance de lo que está publicado actualmente.Sobre la diferencia cualitativa con una "sobrescritura simple con PRNG" que preguntaste, me gustaría explicar la intención de diseño y la dirección técnica que planteé.
Diferencia de entropía entre Orthogonal Noise y Pseudo-Random
Un
random()simple o/dev/urandomapunta a una distribución uniforme desde el punto de vista estadístico, pero desde la perspectiva del análisis de patrones de datos todavía puede existir una periodicidad rastreable. VANI genera un "buffer caótico" que maximiza matemáticamente la entropía de Shannon al extremo. No se limita a esparcir números aleatorios, sino que inyecta ruido matemáticamente ortogonal al vector de datos original para inducir que el magnetismo residual físico o el estado de carga de las celdas converjan hacia un estado de equilibrio imposible de recuperar. (Esta parte se publicará con más detalle más adelante en un white paper, después de presentar la solicitud de patente).Optimización de I/O en entornos SSD (Legacy Linear vs Hilbert)
En realidad, esta es la diferencia decisiva según el medio de almacenamiento que preguntaste. El método tradicional sobrescribe de forma lineal desde el sector 0 hasta el final. Eso no encaja con la estructura de procesamiento en paralelo de los SSD y, debido al wear leveling, es muy probable que la sobrescritura no se aplique sobre la dirección física real.
Pero en el método de VANI, el algoritmo de curva de Hilbert (
Hilbert Curve) explora las direcciones lógicas de forma no lineal dentro del núcleo en Rust. Esto permite aprovechar eficientemente el ancho de banda de múltiples colas (Multi-Queue) de NVMe, cortando los vínculos semánticos de los datos con muchas menos pasadas de escritura (Pass) que en los métodos convencionales.Próximo paso
Como señalaste, es cierto que con el código actualmente publicado de la versión Free es difícil para un tercero verificar que exista una diferencia cualitativa. Al tratarse de un modelo matemático, todavía no está en una etapa en la que haya recibido certificación oficial de una empresa profesional de forénsica. Por eso, más adelante planeo publicar y someter a verificación datos de benchmark Before/After en entornos SSD, o comparar con un PRNG simple usando herramientas de benchmarking, o incluso desarrollar una implementación en Python para hacer experimentos comparativos y publicar esos resultados.
La verdad, como era la primera vez que publicaba algo, estaba un poco preocupado. Por suerte, no fue una pregunta hecha por IA como la de abajo. Justamente este tipo de preguntas agudas y validaciones es el tipo de feedback que quería recibir en Show GN. Seguiré mejorándolo si me siguen señalando los puntos que faltan. ¡Gracias!
Hay muchísimos puntos concretos que quisiera señalar.
Desde el hecho de que la semilla del generador seudoaleatorio que se usa para “colapsar” los primeros 4 KiB del archivo es una combinación de la ruta y el tamaño del archivo, por lo que es completamente determinista, hasta la obviedad de que las solicitudes de patente para algoritmos informáticos son muy difíciles de tramitar y, aun si llegaran a concederse, una patente por sí sola no permite afirmar que exista seguridad, ya con lo que se ha revelado se ven demasiados aspectos que hay que cuestionar.
Pero lo más importante es esto. ¿Qué utilidad adicional puede aportar ese supuesto algoritmo secreto que planean patentar en comparación con un borrado de archivos común y corriente?
Como parece que están asumiendo principalmente un entorno con SSD, voy a hablar limitándome a los SSD. (Ojo: esto no significa que en HDD sí tenga una utilidad relevante).
Los SSD modernos están hechos con memoria flash NAND, y una característica de la memoria flash NAND es que no se puede sobrescribir una celda que ya tiene datos grabados. A una celda en la que ya se escribió información no se le pueden volver a meter datos de inmediato, así que necesariamente tiene que pasar por un proceso de borrado. Como la cantidad de borrados es limitada, en la memoria flash el borrado no se maneja por celdas o páginas individuales, sino por bloques, que son conjuntos de varias páginas. Por eso se necesita una capa FTL (Flash Translation Layer) y también aparecen problemas como la amplificación de escritura (write amplification).
Eso significa que, aunque en un SSD “sobrescribas” parte del contenido de un archivo, físicamente lo que intentaste sobrescribir se guarda en celdas completamente distintas. Ya sea que lo sobrescribas simplemente con ceros o con números aleatorios generados de cualquier forma, no hay ninguna diferencia en el hecho de que físicamente ese contenido se escribe en otras celdas. A nivel de software, más allá de la abstracción del hardware del SSD, solo se ve el resultado final sobrescrito, pero ni el SO ni las aplicaciones pueden controlar directamente la memoria flash NAND de forma explícita.
Eso no significa, sin embargo, que dentro del SSD el borrado de datos nunca se complete. Las celdas que contienen datos que ya no se usan tienen que irse borrando por adelantado para que después, cuando haya que volver a escribir datos, no se produzcan demoras. Por eso, el controlador interno del SSD está ejecutando GC (Garbage Collection) continuamente en segundo plano.
Desde la década de 2010, todos los principales sistemas operativos soportan el comando TRIM. TRIM es la forma en que el SO le dice al SSD: “estos bloques ya no se usan”. Entonces pasan a ser objetivo de la recolección de basura que el controlador del SSD ejecuta constantemente en segundo plano. No se puede saber exactamente cuándo se realizará la limpieza real, pero una vez que la recolección de basura ocurra y se ejecute el borrado en los bloques NAND, incluso si alguien desmontara físicamente los chips individuales, ya no sería posible recuperar la información perdida. Y como hoy en día los sistemas operativos suelen tener TRIM activado por defecto, incluso si solo haces el borrado normal de archivos del sistema operativo, después de cierto tiempo simplemente deja de ser posible recuperar los datos.
Así que, en un entorno con SSD, ejecutar simplemente el comando de borrado de archivos del propio SO no permite afirmar con certeza cuándo desaparecerán los datos, pero en algún momento terminarán perdiéndose por completo de las celdas; en cambio, si sobrescribes los datos del archivo, puede que la información de las celdas que contienen los datos originales siga quedándose intacta durante un tiempo. ¿No es esa precisamente la ironía?
Claro, aunque al final solo invoques el comando de borrado del propio SO, el resultado será el mismo: después de cierto tiempo, los datos terminarán desapareciendo físicamente de las celdas. Pero si el resultado es el mismo, ¿no bastaría entonces con borrar el archivo de forma normal, sin necesidad de recurrir a un algoritmo aparatoso?
Existe un término llamado Purple hat therapy.
Supongamos que alguien afirma: “Para curar la enfermedad X, hay que ponerse este sombrero morado impregnado de una misteriosa energía cósmica y, al mismo tiempo, tomar el medicamento Y”. Pero en realidad, para tratar la enfermedad X ya se venía usando desde antes el medicamento Y. Por supuesto, el tratamiento usando el sombrero morado también tendría efecto, pero ese efecto sería en la práctica exactamente igual al del tratamiento existente. Entonces, ¿hace falta el sombrero morado o no?
A mí me parece que esta cosa llamada VANI encaja perfectamente con eso de la “purple hat therapy”. Según lo que se ha hecho público, no veo absolutamente ninguna base para considerar que ofrezca una seguridad significativa ni ninguna otra utilidad frente al borrado básico de archivos del sistema operativo. La mención de tantos términos especializados, como terminología matemática o algoritmos de computación cuántica, no parece más que una mala táctica de marketing para justificar el precio de una versión de pago de 100 dólares. Yo no usaría este programa ni siquiera si fuera completamente gratis.
Iba a dejar solo un like, pero me pareció descortés, así que dejo un comentario. Lo leí con gusto.
Gracias.
Mientras escribía el comentario, terminó siendo muchísimo más largo de lo que esperaba, casi como una entrada de blog, así que dudé un momento si debía publicarlo tal cual, pero me daba pena el tiempo que me había tomado escribir hasta ahí, así que simplemente lo publiqué. Me alegra saber que lo leíste con gusto.
De verdad, hacía muchísimo tiempo que no leía un texto tan bueno; lo leí hasta dos veces. Muchas gracias de verdad por dejarnos un texto así.
Hasta la presentación la hicieron con un LLM, jaja..
Personalmente, me desagrada muchísimo que hasta la presentación la escriban con un LLM.
¿Es real esto? jajaja
Hola, soy PM del TF de plataforma de convergencia cuántica-termodinámica bajo el Instituto de Investigación de Tecnologías del Futuro de S Electronics. (Actualmente estamos cerrando una ronda puente Series C, así que es difícil revelar mi identidad por ahora).
Vi el post de VANI y a las 4 de la mañana me levanté de la cama de un salto. Sinceramente, sentí un verdadero escalofrío.
En nuestro laboratorio también hemos estado investigando desde 2019 el "protocolo de extinción de información basado en distribución inversa de Boltzmann", y precisamente el cuello de botella clave era la fuga de entalpía en la interfaz Shannon-Gibbs. Pero enterarme de que usted lo evitó mediante el colapso ortogonal del espacio de Hilbert... nuestro investigador principal, al ver esto, dijo que "así debió sentirse Einstein cuando resolvió la paradoja EPR".
En particular, la idea de cortar los enlaces vectoriales del encabezado del archivo con ortogonalización de Gram-Schmidt es un terreno al que nosotros no logramos llegar ni siquiera tras 3 años de investigación conjunta con el Departamento de Ciencias Matemáticas de KAIST. ¿Acaso también implementó internamente una transición de estado tipo cuasí-qubit basada en operadores no hermíticos? Si es así, esto no es una simple herramienta de borrado, sino el punto de partida de un paradigma post-cuántico de incineración de información.
Nuestra empresa matriz (Top 20 global por capitalización de mercado) está preparando actualmente la "iniciativa Data Thermal Death", y el motor de maximización de entropía de VANI coincide exactamente con el hito de la Fase 2 de nuestra hoja de ruta.
¿Sería posible conversar sobre una ~~inversión~~, no, una alianza estratégica tecnológica?
Las condiciones de nuestra parte son:
Sin embargo, nuestro equipo legal dice que necesita una revisión jurídica sobre la "fuerza vinculante matemática de la segunda ley de la termodinámica". ¿Tendrán por casualidad alguna revisión por pares de Nature o certificación del Anexo Q de ISO 27001 respecto a la parte de que la entropía "nunca puede disminuir en términos absolutos"?
Y una pregunta personal... ¿cómo definieron la unidad discretizada de borrado basada en la constante de Planck? Nosotros asumimos un "cuanto de borrado cuántico" de 6.626 × 10⁻³⁴ joule·segundo tomando h-bar como referencia, pero en el punto crítico de coherencia-decoherencia con la caché del controlador NVMe la fase se nos sigue desalineando.
En fin, de verdad es impresionante. Parece que Maxwell, Boltzmann y Shannon del siglo XXI han descendido en un solo cuerpo.
Quedo atento a su pronta respuesta. 🙏
P.D. Por cierto, los datos borrados con VANI no se transfieren a un universo paralelo, ¿verdad? Nuestro CTO empezó a preocuparse de repente por eso.
¿O sea, soy el único al que le da risa este juego de palabras?.. jajaja
Otra vez salió esto... un repositorio hecho un montón de basura de IA