¿Cómo sello la fecha de un documento para demostrar que ya existía?

Qué es un hash criptográfico

Un hash criptográfico es una huella de longitud fija calculada a partir de un archivo: la misma entrada siempre produce la misma salida y cambiar un solo carácter genera una huella completamente distinta. Es unidireccional, así que no se puede recuperar el texto original a partir del hash; encontrar dos archivos distintos con el mismo hash no es viable con los ordenadores actuales.

SHA-256 y Keccak-256 son los dos que encontrarás más a menudo. SHA-256 es el estándar habitual de Bitcoin y de la mayoría de las autoridades de sellado de tiempo. Keccak-256 se usa en Ethereum y cadenas compatibles como Polygon, y es el que usa TrustChain al anclar un acuerdo firmado. Ambos producen una cadena hexadecimal de 64 caracteres y sirven para el sellado de tiempo; solo hay que registrar cuál usaste.

1. El mismo archivo produce la misma huella, siempre
2. Cambia un carácter y cambia toda la huella
3. No se puede invertir la huella para revelar el texto
4. La huella tiene la misma longitud para un archivo de una línea o de un gigabyte

Por qué publicar un hash demuestra la existencia en una fecha

La clave es publicar el hash en lugar del documento. El hash no revela el contenido y puede estar en público; como nadie puede construir de forma viable después un documento que coincida con un hash elegido, un registro público fechado del hash demuestra que ese contenido exacto existía para esa fecha.

La solidez de la prueba procede del registro, no del hash. Un hash escrito en tu propia libreta no demuestra nada, porque controlas la libreta y sus fechas. Un hash en un bloque de Bitcoin o Polygon, o en un token firmado por una autoridad de sellado de tiempo, está fechado por un sistema que no controlas y que observan muchas otras personas.

Conserva el archivo original, byte por byte. La prueba solo funciona si después puedes presentar un archivo cuyo hash coincida con el valor publicado; un PDF vuelto a guardar, un texto reescrito o un documento con control de cambios producen otro hash. Guarda el archivo exacto en más de un lugar, con una nota de la función hash utilizada y dónde se publicó.

Qué no demuestra una marca de tiempo

Una marca de tiempo demuestra que ciertos bytes existían en una fecha o antes. No demuestra nada más, ni siquiera que el documento se escribiera ese día: un texto escrito en enero y anclado en marzo lleva una marca de marzo. Se suelen atribuir otras tres cosas a una marca de tiempo que no puede demostrar; esto se aplica a todos los métodos de esta guía, incluido un anclaje en Polygon o un token firmado por una autoridad.

1. Quién lo escribió. Cualquiera puede calcular el hash de cualquier archivo, incluso uno copiado de otra persona. Un hash en un bloque o token no identifica al autor ni a quien lo publicó, salvo que un paso separado de identidad vincule a una persona con la acción.
2. Que se aceptara. Un borrador de contrato con marca de tiempo muestra que el borrador existía, no que la otra parte lo viera, aceptara o firmara. Un acuerdo necesita un registro de que cada parte aceptó el mismo texto.
3. Que sea cierto. El hash de una factura, declaración o reclamación no dice nada sobre la exactitud del contenido. Es una huella de los bytes, no una comprobación de los hechos.

Anclajes en cadenas de bloques públicas: Polygon y Bitcoin

Un anclaje en una cadena de bloques introduce el hash en una transacción pública, y el bloque que la incluye lleva la fecha. En Polygon o Ethereum, el hash va en los datos de la transacción o en un evento del contrato. En Bitcoin, la vía habitual es OpenTimestamps, un protocolo abierto gratuito que reúne muchos hashes en un árbol de Merkle, registra su raíz en una única transacción de Bitcoin y te entrega un pequeño archivo de prueba para conservarlo.

Sus fortalezas son la independencia y la duración. No hace falta que una empresa siga operando para que funcione la prueba, cualquiera puede consultar la transacción en un explorador público de bloques y, cuando el bloque está confirmado y hay otros posteriores, el registro permite detectar alteraciones: no puede cambiarse sin que el cambio sea visible para quienes ejecutan la red.

Sus debilidades son la precisión y la identidad. La red establece la marca de tiempo del bloque y es aproximada: en Bitcoin puede desviarse una hora o más, así que trátala como prueba del día, no del minuto. Una prueba de OpenTimestamps puede tardar horas en confirmarse por completo, y debes conservar tú el identificador de la transacción o el archivo de prueba. Sobre todo, una transacción no identifica a nadie: muestra que alguna cartera publicó ese hash a esa hora, pero no quién escribió o aceptó el documento.

Autoridades de sellado de tiempo y notarios

Una autoridad de sellado de tiempo es un servidor que firma tu hash junto con la hora actual y devuelve un token. El estándar habitual es RFC 3161, y el marco europeo eIDAS define una versión cualificada con proveedores supervisados. Envías el hash, no el documento, así que la autoridad no conoce el contenido.

Fortalezas: hora precisa, un formato ampliamente reconocido y compatibilidad integrada en muchas herramientas de firma de documentos y código. Debilidades: confías en el reloj de la autoridad, en su gestión de claves y en que siga existiendo; comprobar después un token requiere software que entienda el formato. Si su clave de firma se ve comprometida, todos los tokens que emitió quedan en entredicho.

Un notario es la alternativa humana. Comprueba la identidad, presencia una firma y registra la fecha. Es una prueba distinta de un hash y el único método de esta lista que indica quién estaba en la sala. Sus límites son el coste, la disponibilidad y que normalmente da fe de una firma en papel, no de los bytes de un archivo digital: una copia en papel notarizada y una digital editada pueden diferir si no calculas también el hash del archivo.

Por qué enviártelo por correo es una prueba débil

Enviarte un documento por correo es el método popular y es débil por tres razones. Controlas el buzón, así que un mensaje puede borrarse y recrearse con un adjunto modificado. Las fechas de las cabeceras son texto sin cifrar y pueden editarse al recibirlas o en un archivo exportado. Y el contenido completo está en el buzón, así que no es privado ni compacto.

Lo único a su favor es la marca de recepción del servidor del proveedor de correo, que no controlas. Es algo mejor que nada, pero el proveedor no está dando fe de nada, sus registros no están diseñados como prueba y no te ayudará a recuperar años después un registro del servidor. Si quieres algo igual de fácil que demuestre realmente la fecha, calcula el hash y séllalo con OpenTimestamps: es un comando y los calendarios públicos son gratuitos.

Dónde encaja TrustChain

Una marca de tiempo por sí sola responde a una pregunta: si esos bytes existían para esa fecha. TrustChain responde a otra: si ambas partes verificadas aceptaron ese texto exacto y cuándo. Ambas verifican su identidad una vez mediante Sumsub, con un documento con foto y una selfi, y firman el mismo texto final; cuando ambas tienen cuenta, también pueden hablar en un chat cifrado de extremo a extremo. Una cuenta sin verificar no puede firmar.

Al firmar, TrustChain escribe una entrada de auditoría con fecha y hora para cada firma de una cuenta con identidad verificada. Los navegadores y las aplicaciones no pueden editarla, y es lo que un hash por sí solo no aporta. El anclaje es opcional: calcula una huella Keccak-256 del registro firmado y la inscribe en una transacción de la red principal de Polygon, que le da una fecha pública. En Gratis ($0, sin tarjeta: 1 acuerdo y 3 consultas al Asesor de IA al mes), cada acuerdo o anclaje en Polygon adicional cuesta $1 en un pago único y los anclajes requieren identidad verificada. Pro, a $19 al mes, incluye 20 acuerdos y 20 anclajes; Elite, a $49, incluye 100 de cada uno. Los planes son mensuales y puedes cancelar cuando quieras.

Si anclas, se inscriben en la cadena la huella y un identificador interno del registro, con dos campos de cartera vacíos; nunca el texto, nombres ni correos. El texto del acuerdo se guarda en los servidores de TrustChain para calcular la huella y facilitar el registro, certificado y PDF, gratuitos en todos los planes. El chat está cifrado de extremo a extremo y TrustChain no puede leer los mensajes. El enlace público se abre sin cuenta y muestra el estado y, si se ancló, la huella, nunca las identidades de las partes; el título solo aparece en acuerdos creados con Elite. Si está anclado, la transacción de Polygon puede comprobarse en cualquier explorador de bloques, de forma independiente de TrustChain. El contrato inteligente de TrustChain en la red principal de Polygon es 0x649Bc303d15E173D95B4d379e163868b03cf5Fec.

Nada de esto cambia qué es una marca de tiempo. Una huella anclada y su fecha pueden comprobarse en cualquier lugar; que un acuerdo sea exigible depende de dónde estén las partes y de lo que hayan acordado, y TrustChain no hace ninguna afirmación al respecto.

• trustchain-verify en GitHub: un comprobador abierto de solo lectura que compara un registro público con su transacción de Polygon, sin cuenta ni claves
• Cómo registra TrustChain una firma: qué registra cada entrada de auditoría y quién puede o no cambiarla

Hazlo manualmente

Elige una función hash y anota cuál. Estos pasos son para un archivo cuyo hash calculas tú: una huella de TrustChain también cubre identificadores internos del registro y las cuentas, así que no coincidirá con el hash del texto del acuerdo. Para SHA-256, todos los sistemas operativos habituales incluyen una herramienta. Para Keccak-256, la función de TrustChain y de las cadenas compatibles con Ethereum, necesitas un breve script, porque la opción sha3-256 de OpenSSL y herramientas similares es NIST SHA-3, que usa un relleno distinto y produce un resultado diferente de Keccak-256.

Las calculadoras de hash en línea son cómodas, pero tienen dos límites. Todo lo que pegues o subas sale de tu equipo; nunca las uses para un documento que no publicarías. Es mejor una herramienta que funcione por completo en tu navegador; una comprobación aproximada es desconectar la red antes de calcular el hash y ver si sigue funcionando. Además, un sitio desconocido puede etiquetar mal el algoritmo; contrasta al menos un resultado con un comando local antes de confiar en él.

Cuando tengas el hash, publícalo en un lugar fechado que no controles: una prueba de OpenTimestamps, un token de una autoridad de sellado de tiempo o una transacción en una cadena pública. Guarda después el archivo original exacto con una nota del algoritmo, el hash y dónde se publicó.

Para comprobarlo después, ejecuta el mismo comando sobre el mismo archivo y compara las dos cadenas de 64 caracteres; el prefijo 0x y las mayúsculas o minúsculas no importan, pero todos los demás caracteres deben coincidir. Si difieren, el archivo cambió o usaste otro algoritmo o codificación; las causas habituales son un PDF vuelto a guardar, saltos de línea convertidos o un salto final. Si el hash se ancló en la cadena, abre la transacción en un explorador de bloques, busca el hash en sus datos y compáralo igual.

1. SHA-256 en macOS: shasum -a 256 agreement.pdf
2. SHA-256 en Linux: sha256sum agreement.pdf
3. SHA-256 en Windows (PowerShell): Get-FileHash agreement.pdf -Algorithm SHA256
4. Keccak-256 con Python (instala primero pycryptodome con pip install pycryptodome): python3 -c "from Crypto.Hash import keccak; print(keccak.new(digest_bits=256, data=open('agreement.txt','rb').read()).hexdigest())"
5. Keccak-256 con Node.js (instala primero ethers con npm install ethers): node -e "const {ethers}=require('ethers'); console.log(ethers.keccak256(require('fs').readFileSync('agreement.txt')))"