← Todas las entradas

11 min de lectura

Hash, firma, sella y comparte: los cuatro niveles de una prueba de CardanoWall

CardanoWall construye sus pruebas en cuatro capas: un sello de tiempo basado en un simple hash, una firma opcional, una copia cifrada y sellada, y la entrega privada a destinatarios concretos. Usas solo las capas que cada situación necesita.

Una prueba de CardanoWall tiene cuatro niveles prácticos, y tú decides hasta dónde subir por la escalera:

  • Hash demuestra que esos bytes exactos existían antes de una fecha pública.
  • Firma añade una afirmación respaldada por una clave: una identidad concreta avala el registro.
  • Sella cifra el archivo original para conservarlo de forma privada junto a la prueba.
  • Comparte empaqueta ese archivo sellado para destinatarios concretos, de modo que más tarde puedan descubrirlo y descifrarlo con sus propias claves.

Cada nivel se apoya en el de debajo, y el mismo estándar sostiene a todos: Label 309. Esa es la forma más sencilla de entender qué es CardanoWall: no solo un sitio donde poner hashes en una blockchain, sino una manera por capas de hacer que los registros sean duraderos, privados y verificables, partiendo de un simple sello de tiempo y añadiendo únicamente la protección que la situación realmente exige.

Nivel 1: hash — demostrar que unos bytes exactos existían antes de una fecha

El primer nivel es la clásica prueba de existencia.

Partes de un archivo, un mensaje, un conjunto de datos, un recurso multimedia, un artefacto de compilación, un informe o un manifiesto. CardanoWall calcula un hash criptográfico de esos bytes exactos y publica ese hash en un registro Label 309 en Cardano.

Más tarde, cualquiera que tenga los mismos bytes originales puede volver a calcular el hash. Si coincide con el del registro, el verificador sabe que esos bytes exactos existían a más tardar en el momento del bloque de la transacción. La comprobación se ejecuta contra la cadena pública de Cardano: no necesita ninguna cuenta de CardanoWall ni confía en ningún servidor de CardanoWall.

Lo útil de esto: el archivo nunca tiene que hacerse público. Un contrato privado, una instantánea de un conjunto de datos, el manifiesto de una versión de software o un paquete de pruebas legales pueden llevar cada uno una prueba pública. El registro dice estos bytes existían. No tiene que mostrar los bytes.

¿Para qué sirven las pruebas basadas en un hash?

Las pruebas basadas en un hash son potentes cuando la pregunta tiene que ver con el tiempo y la integridad. Responden a cosas como:

  • ¿Existía este archivo exacto antes de una fecha límite?
  • ¿Es este el mismo PDF que se selló en el tiempo el mes pasado?
  • ¿Estaba ya confirmado este manifiesto de versión antes del incidente?
  • ¿Existía esta instantánea del conjunto de datos antes de entrenar el modelo con ella?
  • ¿Existía este archivo multimedia antes de editarlo o cuestionarlo?

Además son eficientes. Un archivo de varios gigabytes se reduce a un único digest corto, y un archivo privado se convierte en un compromiso público sin revelar su contenido.

La limitación importa igual: un hash no demuestra quién creó el archivo, ni que el archivo sea verdadero, ni que alguien sea su propietario. Demuestra que esos bytes exactos existían antes de una fecha pública; nada más. Para muchos flujos de trabajo, con eso basta. Para el resto, CardanoWall añade las capas siguientes.

Nivel 2: firma — añadir una clave de identidad al registro

El segundo nivel añade una firma.

Una firma permite que una clave avale el registro. En lugar de demostrar solo que unos bytes existían, el registro también puede mostrar que una clave de identidad concreta firmó la prueba. En Label 309 esto es una firma COSE_Sign1 opcional y separada sobre el cuerpo del registro, y la autoría nunca es obligatoria: un registro sin firma sigue siendo una prueba completa y plenamente verificable.

Esa opción cambia el significado práctico. Para un creador individual, un registro firmado puede vincular un trabajo a la identidad de CardanoWall de su autor. Para una empresa, puede mostrar que una clave aprobada respaldó un informe, un manifiesto de versión, una instantánea de cumplimiento o un compromiso sobre un conjunto de datos. Para un flujo de trabajo automatizado, distingue entre «alguien selló en el tiempo este archivo» y «nuestro sistema firmó este registro como parte del proceso».

La firma no sustituye al hash; se asienta sobre él.

  • El hash dice: estos bytes exactos existían.
  • La firma dice: esta clave firmó el registro que hace esa afirmación.

¿Qué no demuestra una firma?

Las firmas son potentes, pero no son magia.

Una firma demuestra el control de una clave en el momento de firmar. No demuestra, por sí sola, la identidad en el mundo real de la persona o la empresa detrás de esa clave. Esa identidad procede del contexto: cómo se creó la clave, cómo se publicó, cómo la gestiona una organización y cómo otros llegan a confiar en ella.

Una firma tampoco demuestra que quien firmó pagara la comisión de la transacción ni que enviara la transacción a Cardano. En Label 309 la firma cubre el cuerpo del registro, no toda la transacción de Cardano. Esto es deliberado, y es lo que mantiene los registros portables: un gateway, un sistema de automatización o cualquier tercero puede publicar un registro firmado sin convertirse en el autor del contenido. Una firma verificada se lee como «firmado por esta clave»; nunca como «esta clave envió la transacción».

En términos sencillos: firma cuando quieras que la prueba diga no solo «esto existía», sino «esta identidad respaldó la prueba».

Nivel 3: sellar — conservar una copia cifrada junto a la prueba

El tercer nivel añade conservación cifrada.

Una prueba basada solo en un hash tiene una debilidad práctica: el verificador todavía necesita los bytes originales. Si pierdes el archivo, o lo cambias aunque sea un byte, ya no puedes producir el contenido que coincide con el registro.

Sellar resuelve esto cifrando el archivo y manteniendo la carga cifrada junto a la prueba, en una ubicación direccionada por contenido como Arweave o IPFS. El registro en la cadena sigue comprometiéndose con el hash del texto plano —nunca con el texto cifrado—, así que la afirmación del sello de tiempo no cambia. El archivo nunca se publica en claro. Cualquiera que tenga la clave correcta puede más tarde descargar el texto cifrado, descifrarlo, recalcular el hash del texto plano y demostrar que ese es el archivo que hay detrás del registro.

Eso cambia la experiencia. Con una prueba basada solo en un hash, guardas el archivo original tú mismo. Con una prueba sellada, puedes conservar una copia cifrada del original como parte del propio flujo de la prueba.

¿Cuándo merece la pena sellar?

Sellar importa cuando el archivo original es lo bastante valioso como para que perderlo debilite la prueba. Piensa en:

  • paquetes de pruebas legales y contratos firmados;
  • informes de cumplimiento y registros de incidentes sensibles;
  • archivos creativos originales y datos de investigación;
  • manifiestos de conjuntos de datos, prompts y salidas de IA, y artefactos de versión.

En cada caso el hash es útil, pero los bytes originales son lo que quizá necesites producir más adelante. La prueba de existencia sellada te permite mantener esos bytes cifrados mientras el sello de tiempo sigue siendo público. La cadena demuestra la línea temporal; el cifrado protege el contenido.

Nivel 4: compartir — entregar un archivo sellado a destinatarios concretos

El cuarto nivel añade la entrega privada a destinatarios.

A veces la prueba no es solo para ti. Puede que necesites enviar pruebas cifradas a un abogado, un auditor, un socio, un periodista, un cliente, un regulador o un equipo interno.

Si conoces la dirección de recepción del destinatario, CardanoWall puede crear un registro sellado que el destinatario podrá abrir más tarde con su propia clave. Ese registro sigue teniendo un sello de tiempo público y sigue comprometiéndose con el hash del texto plano. Sigue pudiendo conservar un archivo cifrado. Pero ahora la carga cifrada pueden abrirla destinatarios concretos, y no solo el remitente. Aquí es donde CardanoWall empieza a parecer menos una herramienta de sellos de tiempo y más un sistema seguro de entrega de registros.

¿Cómo funciona la entrega privada sin una agenda pública?

La entrega a destinatarios no necesita ninguna agenda pública en la cadena, y la clave pública de ningún destinatario se escribe jamás en el registro como un campo legible.

Así es el flujo. Un destinatario tiene una dirección de recepción. El remitente la obtiene fuera de banda: directamente del destinatario, de un perfil, de la página de una empresa o de otro canal de confianza. Cuando el remitente construye un registro sellado, el sobre lleva ranuras de clave cifradas por destinatario que solo los destinatarios previstos pueden abrir.

En el lado receptor, el software del destinatario rastrea los registros sellados públicos y hace un descifrado de prueba: intenta localmente cada ranura con sus propias claves. Cuando una ranura se abre, el registro aparece en el Inbox de ese destinatario. El servidor nunca descifra el mensaje y no necesita saber quién es el destinatario. (Consulta cómo recibir registros sellados para ver el lado del destinatario en detalle).

Esto no es una promesa de anonimato perfecto. Los tiempos, los flujos de pago, los metadatos de red, el comportamiento del navegador y los errores operativos todavía pueden filtrar información, y un destinatario siempre puede compartir el texto plano una vez que lo ha descifrado. Lo que el diseño sí ofrece es algo más acotado y real: el propio registro Label 309 no publica ni el texto plano ni una lista de destinatarios legible por humanos. Un observador solo ve que un registro está sellado y cuántas ranuras de clave lleva, nunca a quién van dirigidas.

¿Por qué el cifrado poscuántico forma parte de la historia de compartir?

Los registros sellados pueden vivir mucho tiempo. Si el contenido cifrado se almacena de forma permanente o semipermanente, un atacante no necesita romperlo hoy: puede guardar el texto cifrado ahora e intentarlo más tarde, con mejor hardware y mejor criptoanálisis. Este es el problema de «recolectar ahora, descifrar después».

Por eso Label 309 se toma en serio la agilidad algorítmica. Las direcciones de recepción vienen en dos formas: una dirección clásica X25519 y una dirección híbrida poscuántica opcional que combina X25519 con ML-KEM-768 (una construcción al estilo de X-Wing). La híbrida mantiene la seguridad clásica de X25519 como un suelo mínimo a la vez que añade resistencia frente a un futuro atacante cuántico, así que es la mejor opción por defecto para contenido pensado para sobrevivir a las suposiciones criptográficas de hoy. La idea no es afirmar una seguridad permanente —nada honesto puede hacerlo—, sino evitar diseñar un sistema de pruebas que dé por hecho que la comodidad criptográfica actual durará para siempre.

La versión de cara al usuario se mantiene sencilla: protege tu semilla de identidad, prefiere la dirección de recepción híbrida poscuántica cuando tu destinatario publique una, y deja que el software se encargue de la criptografía.

¿Cómo funcionan juntos los cuatro niveles?

Los niveles no son productos separados. Son capas sobre un único estándar:

  • Publica una prueba con un simple hash cuando solo necesitas un sello de tiempo.
  • Añade una firma cuando quieres que una clave de identidad avale el registro.
  • Sella el archivo cuando conservar los bytes originales exactos importa.
  • Comparte el archivo sellado cuando destinatarios concretos necesitan acceso privado.

Como el mismo estándar de base admite cada opción, puedes empezar de forma sencilla y recurrir a capas más fuertes solo cuando la situación lo exija.

¿Qué nivel deberías usar?

  • Hash cuando el archivo original es fácil de conservar y la única pregunta es si esos bytes existían antes de cierta fecha.
  • Firma cuando quieres que una identidad respaldada por una clave avale la prueba.
  • Sella cuando los bytes originales son lo bastante sensibles o importantes como para conservar una copia cifrada junto a la prueba.
  • Comparte cuando otra persona necesita recibir el contenido cifrado y verificarlo más tarde.

Hay además una quinta herramienta que atraviesa las cuatro: la agrupación de Merkle, para cuando tienes demasiados hashes como para publicarlos uno a uno —artefactos de CI/CD, registros diarios, instantáneas de conjuntos de datos, medios generados o cualquier flujo de trabajo donde miles de elementos deberían comprometerse bajo un único registro y una única raíz.

¿Qué siguen sin demostrar estas pruebas?

Incluso con los cuatro niveles, la prueba de existencia mantiene la precisión sobre lo que afirma.

Puede demostrar que unos bytes exactos existían, que una clave firmó el registro, que se conservó contenido cifrado, que el contenido se entregó a claves concretas y —con una raíz de Merkle— que un elemento pertenecía a un lote comprometido.

No demuestra, por sí sola, que el contenido sea verdadero, que alguien posea la propiedad legal, que un conjunto de datos se recopilara de forma lícita ni que un proceso débil sea sólido. Para más detalle sobre esos límites, consulta lo que una prueba no demuestra. CardanoWall te da una capa de prueba duradera; el proceso de negocio en torno a esa prueba sigue importando.

La versión corta

  • Hash es el sello de tiempo.
  • Firma es la afirmación de identidad.
  • Sella es la conservación cifrada.
  • Comparte es la entrega privada.

Juntos convierten la prueba de existencia de un simple hash sobre una cadena en un flujo de trabajo útil para archivos, conjuntos de datos, pruebas, versiones de software, salidas de IA y registros confidenciales. Y como Label 309 es un estándar abierto con herramientas de código abierto, los mismos cuatro niveles funcionan a través del sitio web, de la CLI o de la implementación de cualquier otra persona.

Más lecturas

cardanowalllabel-309proof-of-existence