Divulgación confidencial sin publicar el archivo

Puedes demostrar que un archivo existía en un momento concreto sin hacerlo público.

Eso es justo lo que hace un registro Label 309 sellado. El remitente calcula el hash del texto plano, cifra el archivo y publica un registro de prueba en Cardano. El texto cifrado se guarda en una ubicación direccionada por contenido y solo se pone a disposición de quienes tienen la clave para descifrarlo. La blockchain pública demuestra que un compromiso concreto existía antes de una hora de bloque pública; el texto plano sigue siendo legible solo para el público elegido.

Esto encaja en el trabajo jurídico, de cumplimiento, de seguridad, de periodismo, con socios y en investigaciones internas: en cualquier sitio donde la cronología importa pero el documento no debería acabar publicado en la internet abierta.

¿Qué significa aquí divulgación confidencial?

Significa compartir material probatorio con un público concreto en lugar de con el mundo entero.

Ese público puede ser un abogado, un auditor, un regulador, un periodista, un equipo de investigación interna, el contacto de seguridad de un cliente, un comité del consejo, un socio —o una versión futura de ti mismo.

El objetivo es demostrar que el material probatorio existía en un momento concreto sin poner el texto plano en una blockchain pública ni en un sitio web público. La prueba de existencia sellada está hecha exactamente para esa forma: una afirmación pública sobre el tiempo respecto a un archivo privado.

¿Qué va realmente a la cadena pública?

El registro de prueba se hace público. El texto plano no.

El registro en cadena puede llevar:

el hash del texto plano —esta es la prueba del momento—;
la hora de bloque de la transacción de Cardano;
un sobre de cifrado que contiene el material de clave envuelto;
una o varias URIs de texto cifrado direccionadas por contenido (ar:// o ipfs://);
una firma opcional, si el remitente decide firmar;
una raíz de Merkle, si la divulgación cubre muchos archivos a la vez.

El registro deliberadamente no lleva:

el archivo en texto plano;
una lista legible de destinatarios;
la clave privada de ningún destinatario;
tu semilla de identidad;
el material probatorio descifrado.

Conviene decir con claridad un matiz: las claves públicas de los destinatarios tampoco aparecen nunca en la cadena. Un destinatario no se nombra en el registro; descubre que un registro es suyo solo al lograr un descifrado de prueba. Un observador ve que un registro está sellado, conoce su hash del texto plano y su hora de bloque, y puede contar las ranuras de clave envueltas, pero las ranuras se barajan en un orden aleatorio seguro antes de la publicación, así que ni siquiera «primero el destinatario principal» filtra nada. El recuento te dice cuántos, nunca quién.

El texto cifrado en sí lo puede descargar cualquiera que tenga la URI. Sin una clave que corresponda, sigue siendo ilegible.

¿Cómo abre un destinatario un registro sellado?

El destinatario comparte una dirección de recepción con el remitente, y el remitente sella el registro hacia ella.

Una dirección de recepción no es más que una clave pública. El remitente envuelve la clave de cifrado del archivo hacia esa dirección. Después, el cliente del destinatario explora los registros Label 309 públicos e intenta abrir las ranuras de clave cifradas de cada registro con sus propias claves de recepción privadas —todo en local, en el dispositivo del destinatario—. Nada sobre qué registros son suyos sale jamás de la máquina.

Cuando una ranura se abre, el cliente obtiene el texto cifrado, lo descifra, recalcula el hash del texto plano y comprueba ese hash contra el compromiso en cadena. Una coincidencia confirma dos cosas a la vez: el destinatario tiene el archivo real, y ese archivo exacto es el comprometido en la hora de bloque registrada.

Como el destinatario posee una clave privada, aquí es donde la verificación pasa de «existía un compromiso» a «este contenido concreto existía». Para la mecánica del lado del remitente —compartir una dirección de recepción y recibir registros sellados—, consulta cómo recibir registros sellados.

¿Por qué no enviar sin más el archivo cifrado por correo?

El correo puede mover archivos, pero no es un sello de tiempo duradero y verificable de forma independiente.

Un mensaje se puede borrar, alterar o perder. Los adjuntos se eliminan. Los servidores de correo se dan de baja. Los formatos de exportación son caóticos y difíciles de autenticar años después. Nada de eso le da a un verificador una forma de demostrar cuándo existía el archivo.

Un registro Label 309 sellado le da al archivo un ancla de prueba pública que no depende de tu buzón ni del servidor de nadie. La carga cifrada se puede conservar por separado, y el destinatario puede demostrar más tarde que el contenido descifrado coincide con un hash comprometido en una cadena pública. Todavía puedes avisar al destinatario por correo; solo que no dejes que la prueba dependa de ello.

¿Por qué no subir sin más el archivo cifrado a un almacenamiento privado?

Puedes hacerlo, y a menudo deberías. Pero el almacenamiento privado por sí solo no te da ningún ancla de tiempo pública.

El bucket de almacenamiento de una empresa, una herramienta de gestión de casos o un portal seguro pueden guardar archivos cifrados perfectamente. Lo que ninguno de ellos responde por sí mismo es: ¿puede un verificador posterior demostrar cuándo existía ese paquete cifrado, y que el texto plano descifrado coincide con un compromiso público? Sin eso, «teníamos este archivo en marzo» es una afirmación, no una prueba.

Label 309 añade el compromiso con sello de tiempo. No reemplaza tu almacenamiento seguro: le da a ese almacenamiento una capa de prueba verificable encima.

¿Cuándo debería firmarse el registro de divulgación?

Fírmalo cuando la responsabilidad importa más que el anonimato.

Firmar un registro es opcional. Una firma permite que una clave de identidad concreta responda por la divulgación —útil cuando una empresa envía un paquete de pruebas formal a un auditor, o cuando un equipo legal necesita un registro responsable y atribuible—. La firma es una afirmación de autoría respaldada por clave pública, y un verificador puede comprobarla sin confiar en ningún servidor.

Deja el registro sin firmar cuando importa más el anonimato del remitente. Un registro sellado sin firmar no vincula en la cadena ninguna identidad de remitente, que es exactamente lo que necesitan las filtraciones de un denunciante y los escenarios de plica con oferta sellada. Esa disyuntiva debería ser una decisión deliberada: una firma puede establecer quién respaldó la divulgación, y en contextos sensibles esa misma atribución puede revelar más de lo que el remitente quiere.

¿Puede un registro llegar a varios destinatarios?

Sí. Un único registro sellado puede envolver la clave de cifrado del archivo en ranuras separadas para varios destinatarios.

Cada destinatario abre el registro con su propia clave, y un destinatario no puede usar su ranura para derivar la clave de otro. Eso cubre a un bufete y su cliente, a un equipo de investigación interna, a un auditor y un contacto de la empresa, a varios reguladores a la vez, a un comité del consejo —o a un remitente que conserva para sí una copia recuperable mientras la comparte con otros—.

El registro público puede revelar el número de ranuras, pero nunca una lista legible de a quién pertenecen.

¿Y un paquete de pruebas grande con muchos archivos?

Usa un manifiesto y agrupación de Merkle en lugar de una transacción por archivo.

Calcula el hash de cada archivo en una hoja, pliega las hojas en una única raíz de Merkle y publica esa raíz en el registro Label 309. Sella el manifiesto y los archivos de respaldo según haga falta. Después, un destinatario o un auditor puede verificar cualquier archivo individual con una prueba de inclusión corta —totalmente sin conexión— en lugar de tratar todo el paquete como un archivo opaco. Las pruebas de inclusión crecen solo con el logaritmo del tamaño del lote, así que una divulgación de mil archivos sigue verificándose elemento por elemento.

Este es el mismo patrón de una-raíz-para-muchos-archivos que se describe en un registro para miles de archivos; aquí hace que las divulgaciones grandes sean inspeccionables en lugar de todo-o-nada.

¿Qué demuestra realmente un registro sellado?

Las afirmaciones son sólidas, pero son específicas. Un registro Label 309 sellado puede mostrar:

que esos datos exactos existían antes de una hora de bloque pública;
que el texto cifrado descifrado coincide con el hash del texto plano comprometido;
que una clave concreta firmó el registro, si el registro está firmado;
que un archivo concreto se incluyó en un conjunto de pruebas agrupado con Merkle;
que un destinatario que posee la clave y el texto cifrado tuvo acceso a material probatorio descifrable.

Cada una de esas es una afirmación precisa y comprobable de forma independiente sobre el momento y la integridad.

¿Qué no demuestra?

Igual de importante: esto es lo que no establece:

No demuestra que el material probatorio sea cierto. Una prueba certifica bytes y momento, no hechos.
No demuestra que el remitente tuviera derecho legal a divulgar el archivo.
No demuestra la identidad real del destinatario salvo que la dirección de recepción se haya verificado mediante un proceso de confianza. Confirmar quién posee de verdad una dirección es un paso aparte: consulta verifica un destinatario antes de sellar un archivo.
No proporciona anonimato. Los patrones de tiempo, los metadatos de red, los rastros de gateway y de pago, las huellas de dispositivo y los errores operativos pueden revelar información que vive fuera del registro. Un destinatario también puede filtrar el texto plano una vez que lo ha descifrado.
No reemplaza al asesoramiento legal ni a los procedimientos de divulgación segura, y que una prueba dada ayude en un litigio depende de la jurisdicción.

Para la versión general de este límite, consulta lo que una prueba no demuestra.

¿Cómo debería preparar esto un equipo antes de necesitarlo?

Define el flujo de divulgación antes de la crisis, no durante ella. Decide por adelantado:

quién puede crear divulgaciones selladas;
qué identidad, si la hay, firma los registros formales;
qué direcciones de recepción son de confianza, y cómo se verificaron;
dónde se guarda el texto cifrado;
a quién se le permite descifrar;
cómo se estructuran los manifiestos para los paquetes de varios archivos;
cómo se registran y se traspasan las referencias de transacción;
cómo se exporta el material probatorio para la revisión legal.

La criptografía es solo una capa. El proceso que la rodea es lo que determina si la prueba es realmente útil cuando llega la presión. Para una perspectiva de manejo de pruebas, consulta pruebas legales y e-discovery y, para fuentes de mayor riesgo, pruebas de denunciantes.

La versión corta

La divulgación confidencial necesita dos cosas a la vez: privacidad y prueba.

Los registros Label 309 sellados mantienen el archivo cifrado para los poseedores de clave elegidos mientras publican un compromiso público, con sello de tiempo, sobre su hash. Los destinatarios descifran en local y confirman que el texto plano coincide con el hash en cadena. Las firmas, las raíces de Merkle y las ranuras multidestinatario añaden opciones de flujo más potentes cuando las necesitas.

Úsalo para demostrar la cronología sin publicar nunca el archivo.

Para seguir leyendo

Label 309 —el estándar abierto y neutral respecto al proveedor de prueba de existencia que hay detrás de los registros sellados—. Label 309 es la etiqueta de metadatos en cadena; la propuesta está en revisión en el proceso de CIP de Cardano como una CIP de la categoría Metadata (PR abierto).
CardanoWall open source —el corpus del estándar, los SDK y la herramienta de línea de comandos cardanowall que puede construir, sellar y verificar registros—.
Lo que una prueba no demuestra —los límites de cualquier prueba de existencia—.
Verifica un destinatario antes de sellar un archivo —el error humano más común en los flujos cifrados—.