Pruebas de un denunciante: ponles un sello de tiempo sin publicarlas

Una prueba de existencia sellada puede preservar las pruebas de un denunciante sin publicar jamás los archivos. El remitente calcula el hash de las pruebas, las cifra para un único destinatario elegido y publica un registro Label 309 en Cardano. El registro en cadena lleva solo el hash y las claves envueltas: nunca el texto plano y nunca la identidad del destinatario. Más tarde, el destinatario descifra el archivo y confirma que coincide con el compromiso sellado en el tiempo.

Eso prueba que las pruebas existían antes de un momento público y que llegaron a un titular de clave concreto. No vuelve anónimo al remitente, no lo mantiene a salvo, no le concede protección legal ni garantiza que nada vaya a admitirse ante un tribunal. Trata un registro sellado como una capa de prueba y cifrado, no como una estrategia de divulgación por sí sola.

¿Qué problema resuelve esto en realidad?

Las pruebas son frágiles. Un archivo se puede borrar. Un documento se puede editar. Una captura de pantalla se puede impugnar. La exportación de una base de datos se puede regenerar y antedatar. Con frecuencia, un denunciante necesita demostrar que un archivo concreto existía antes de una divulgación, de una reclamación por represalias, de una auditoría o de una demanda, y demostrarlo sin depender de la buena voluntad de la organización a la que se refieren las pruebas.

A la vez, publicar el archivo en abierto puede ser peligroso, ilegal o sencillamente incorrecto. Puede exponer a terceros ajenos, secretos comerciales o historiales médicos.

Un registro Label 309 sellado separa la prueba del texto plano. La línea temporal puede ser pública y permanente. El contenido permanece cifrado para un único destinatario. Obtienes el sello de tiempo sin pagar el precio de la divulgación.

¿Cómo funciona la prueba sellada, paso a paso?

El flujo es el mismo que se describe en hash, firmar, sellar, compartir, aplicado a material sensible:

el remitente prepara el archivo de pruebas, o un manifiesto de pruebas que describe muchos archivos;
el software calcula el hash del texto plano;
el contenido se cifra para la dirección de recepción del destinatario: la clave de contenido se envuelve con la clave pública del destinatario en un sobre sellado al estilo de age;
el texto cifrado se almacena en una ubicación direccionada por contenido (ar:// o ipfs://). Allí solo se almacena el texto cifrado; el texto plano nunca;
se publica un registro Label 309 en Cardano, que lleva el hash y la clave envuelta, no el texto plano ni la clave pública del destinatario;
más tarde, el destinatario obtiene el texto cifrado y lo descifra en local;
el destinatario vuelve a calcular el hash del texto plano y lo compara con el registro.

El registro prueba cuándo existió el compromiso. El archivo descifrado prueba sobre qué trataba el compromiso. Hacen falta las dos mitades, y la segunda queda en privado para el titular de la clave.

¿Por qué no poner las pruebas directamente en la blockchain?

Porque una cadena pública es permanente, y algunas pruebas no se pueden hacer públicas de forma segura jamás. El material sensible puede contener datos personales, información confidencial de negocio, detalles médicos, secretos comerciales, credenciales, vulnerabilidades de seguridad, los nombres de personas ajenas o contenido legalmente restringido. Una vez que eso está en un libro mayor público, ya no se puede retirar.

Una prueba sellada permite al remitente comprometerse con los bytes exactos sin exponerlos. El destinatario recibe y verifica el contenido en privado, mientras que el resto del mundo solo ve que se publicó algún registro sellado en un momento de bloque concreto. Es el mismo patrón que se trata en divulgación confidencial sin archivos públicos.

¿Quién debería ser el destinatario? ¿Y cómo llegar al correcto?

Elige al destinatario con criterio. Puede ser un periodista, un abogado, un regulador, una oficina de ética interna, un auditor, una organización de la sociedad civil o un investigador de confianza. El requisito ineludible es que el remitente debe disponer de una dirección de recepción que pertenezca de verdad al destinatario previsto.

Una dirección de recepción no es más que una cadena de clave pública (tiene el aspecto de age1…). Por sí sola no prueba nada sobre quién la controla: Label 309 no especifica de forma deliberada ningún directorio ni ningún registro de confianza de claves. Por eso, ante pruebas sensibles, el remitente debería confirmar la dirección por un canal en el que ambas partes ya confíen, tal como se describe en verificar a un destinatario antes de sellar un archivo.

Equivócate en esto y el coste es real: envía las pruebas a la clave equivocada y quedarán ilegibles para la persona a la que querías hacérselas llegar, o legibles para alguien que no querías.

¿Debería el remitente firmar el registro?

Por lo general, no, si el objetivo es evitar la atribución.

Una firma a nivel de registro vincula el registro a una clave pública. Eso es útil cuando una empresa o una persona con nombre quiere rendir cuentas. Es arriesgado cuando el remitente necesita evitar que la divulgación se vincule a una identidad.

En Label 309, las firmas de autoría son siempre opcionales. Un registro sellado sin firmar sigue probando que el compromiso con las pruebas existía antes de un momento público: simplemente no hace ninguna afirmación pública de autoría y, en la cadena, no vincula identidad alguna del remitente. La contrapartida es sencilla:

los registros firmados añaden rendición de cuentas;
los registros sin firmar evitan una atribución pública respaldada por clave.

Cuál de los dos es el adecuado depende por completo del contexto legal y de seguridad, y esa es una decisión que se toma con asesoría legal, no a partir de una entrada de blog.

¿Un registro sellado vuelve anónimo al remitente?

No. Esta es la limitación más importante de todas, así que conviene ser tajante.

Un registro Label 309 sellado y sin firmar mantiene fuera de la cadena el texto plano, la identidad del destinatario y cualquier firma del remitente, y el feed global de registros es ciego al destinatario: nada en él apunta de vuelta a quién puede descifrar. Pero el anonimato depende de mucho más que de los bytes de un único registro. Todo lo que queda fuera del registro todavía puede exponer al remitente:

los metadatos de red y las direcciones IP;
las huellas de navegador o de dispositivo;
un dispositivo comprometido;
los rastros de pago;
la actividad de la cuenta del gateway;
la correlación temporal entre publicaciones;
los metadatos de archivos, documentos y cámara;
el estilo de redacción;
los errores operativos;
el canal usado para hablar con el destinatario.

La criptografía no puede resolver esto. Pertenece al ámbito de las herramientas dedicadas a la protección de fuentes, de la seguridad operativa y del asesoramiento legal. No trates una prueba de existencia sellada como un sistema de anonimato: trátala como una forma de ponerle un sello de tiempo y de cifrar, y combínala con las herramientas adecuadas para todo lo demás.

¿Qué puede verificar el destinatario una vez que tiene el archivo?

Un destinatario con la clave privada correspondiente puede comprobar toda la cadena de afirmaciones:

que el registro Label 309 existe en Cardano;
el momento de bloque y el contexto de confirmación de ese registro;
que su clave abre una de las ranuras del sobre, recuperando la clave de contenido;
que el hash del texto plano recalculado coincide con el hash comprometido en la cadena;
una prueba de inclusión de Merkle, si las pruebas eran una hoja dentro de un paquete mayor;
una firma del registro, si el remitente eligió firmar.

Cualquiera que no tenga una clave correspondiente —incluido un verificador público— aún puede confirmar que el registro existe, que su sobre está bien formado y que la URI del texto cifrado es accesible. Lo que no puede hacer es descifrarlo ni averiguar a qué se compromete. Esa separación es precisamente el objetivo: la cadena atestigua un compromiso, y solo el titular de la clave confirma sobre qué versa.

¿Qué no prueba una prueba sellada?

Un sello de tiempo es estrecho a propósito. Un registro sellado no prueba:

que las pruebas sean ciertas;
que el remitente esté protegido por la ley de protección al denunciante;
que la divulgación sea legal;
que el destinatario sea de fiar, ni que vaya a mantener confidencial el texto plano;
que el archivo se obtuviera de forma lícita;
que el remitente sea anónimo.

Y, una vez que un destinatario descifra el contenido, nada le impide compartirlo: el cifrado protege el archivo en tránsito y en reposo, no la discreción del destinatario después.

Lo que un registro sellado sí prueba es exacto y útil: un compromiso con sello de tiempo sobre unos bytes concretos, entregado a un titular de clave concreto. No sustituye al asesoramiento legal, ni a la práctica periodística de protección de fuentes, ni a las herramientas de comunicación segura, ni a un plan de seguridad. Para profundizar en este límite, consulta lo que una prueba no prueba.

¿Por qué sellar un manifiesto en lugar de un único archivo?

Las pruebas suelen llegar como un paquete, no como un único archivo ordenado. En lugar de sellar un archivo opaco, el remitente puede construir un manifiesto de pruebas que registre:

nombres de archivo o identificadores neutros;
hashes por archivo;
el momento de recopilación;
notas de origen y de cadena de custodia;
el estado de las redacciones;
la información del destinatario;
las hojas de Merkle y las pruebas de inclusión.

Las entradas sensibles pueden cifrarse a su vez. El manifiesto ayuda al destinatario a entender qué se divulgó y a verificar archivos concretos más tarde. Para conjuntos grandes, una única raíz de Merkle compromete todo el paquete sin dejar de permitir que cada archivo se compruebe por su cuenta: el enfoque de un registro para miles de archivos.

¿Cómo debería prepararse una organización para recibir divulgaciones selladas?

Las organizaciones deberían hacer el trabajo de base antes de invitar a nadie a enviar pruebas sensibles. Eso significa publicar las direcciones de recepción con cuidado, rotarlas o retirarlas cuando haga falta, verificar la titularidad de la dirección de extremo a extremo, proteger las semillas de los destinatarios que pueden descifrar, definir con claridad quién está autorizado a descifrar y documentar cómo se gestionan las pruebas selladas.

También deberían ser honestas con las fuentes acerca de los límites. Una dirección de recepción no es un sistema completo de buzón seguro; es un componente de un proceso de recepción. Una organización que quiera dar soporte a divulgaciones de verdad de alto riesgo necesita procedimientos legales, de seguridad y operativos que envuelvan a la criptografía, no la criptografía a secas.

¿De qué sirve esto más adelante, en una disputa?

Establece la línea temporal de las pruebas. Si surge una cuestión más tarde, el destinatario quizá pueda mostrar:

la referencia de la transacción de Cardano;
el registro Label 309 y su momento de bloque;
la carga cifrada;
las pruebas descifradas;
el hash del texto plano coincidente;
la prueba de inclusión de Merkle, para un archivo dentro de un paquete;
el hecho de que el compromiso existía antes de una fecha concreta.

Eso puede respaldar una investigación, un informe, una revisión legal o un proceso interno de rendición de cuentas. Y, como la verificación solo necesita los metadatos de la transacción, los bytes y un explorador público de Cardano, no depende de que CardanoWall siga existiendo. Son pruebas sobre la existencia y la integridad, no sobre quién tiene razón. El patrón relacionado para las divulgaciones corporativas con plazos ajustados se trata en líneas temporales de incidentes de seguridad, y el contexto judicial más amplio, en pruebas legales y e-discovery.

La versión corta

Un registro Label 309 sellado permite a un denunciante y a un destinatario elegido preservar pruebas en privado. Le pone un sello de tiempo a un compromiso, cifra los archivos para un único destinatario y permite que ese destinatario pruebe más tarde que los bytes descifrados coinciden con el registro público.

No garantiza anonimato, legalidad, seguridad ni verdad, y un destinatario puede filtrar lo que descifra. Úsalo como una capa cuidadosa dentro de un proceso de divulgación más amplio y bien asesorado, nunca como el plan completo.

Más lecturas

Divulgación confidencial sin archivos públicos
Verifica a un destinatario antes de sellar un archivo
Lo que una prueba no prueba
El estándar Label 309: label309.org
El código abierto, la CLI y los SDK: github.com/cardanowall