Cómo demostrar que un documento no se reescribió después

Por qué no sirven las respuestas obvias

• La fecha del documento. La escribió quien lo redactó y la puede cambiar quien lo edite.
• La fecha de modificación del archivo. Es una propiedad de su copia, no del documento. Copiarlo la reinicia.
• La fecha de publicación en la página. Un campo en una base de datos que controla el editor.
• Internet Archive. Genuinamente útil, y fuera del control del editor, pero captura lo que le tocó visitar cuando le tocó visitarlo. Sin captura, no hay prueba.

Ninguna de estas cosas es deshonesta por naturaleza. Sencillamente no son prueba, porque la parte a la que deberían limitar es la misma que las controla.

Qué sí funciona

Dos piezas, y ninguna exige confiar en el editor.

Una suma de verificación —un hash SHA-256— es una cadena corta calculada a partir de los bytes de un archivo. Cambie un carácter en cualquier sitio y la cadena cambia por completo. No se puede invertir ni falsificar: no se puede fabricar un documento distinto con el mismo hash. Así que un hash publicado fija un único archivo exacto.

Una prueba de sello de tiempo ata ese hash a un momento comprometiéndolo en la cadena de bloques de Bitcoin. Reescribir ese registro exigiría reescribir Bitcoin. Lo que prueba es estrecho y útil: este archivo exacto existía no más tarde de este bloque.

Comprobar uno en dos comandos

Descargue el documento y su archivo de prueba, normalmente un archivo pequeño terminado en .ots que está a su lado. Después calcule el hash y compárelo con el valor publicado:

sha256sum document.docx

Si coincide, usted tiene el archivo exacto que se publicó. Ahora verifique cuándo existía, con el cliente de OpenTimestamps:

ots verify document.docx.ots

El cliente informa del bloque de Bitcoin y su fecha. Esa es la prueba, y no contacta con el proyecto en absoluto: solo con la cadena de bloques.

Una advertencia práctica que pilla a mucha gente: abrir un documento en un procesador de textos y guardarlo, aunque no se edite nada, reescribe los bytes. La suma deja de coincidir y la prueba ya no encaja. Verifique antes de editar y conserve el original.

Qué prueba y qué no

• Prueba: que este archivo existía con esta forma exacta en esa fecha o antes.
• No prueba: quién lo escribió. Cualquiera puede sellar el documento de cualquiera.
• No prueba: que su contenido sea cierto. Una previsión sellada sigue siendo una previsión con fecha.
• No prueba: que fuera la única versión. Un proyecto puede sellar varios borradores y enseñarle el que le favorece, por lo que el conjunto de pruebas publicadas importa tanto como cualquier prueba aislada.

Por qué lo hacen tan pocos proyectos

No cuesta nada. Los calendarios son gratuitos, el cliente se instala como un paquete y sellar lleva un segundo. La razón de que sea raro no es el coste: es que elimina una opción. Una vez sellado un documento, la revisión silenciosa queda descartada, y las cifras que contiene hay que defenderlas en vez de ajustarlas.

Lo que hace que su ausencia sea informativa. Un proyecto que publica documentos sin sumas de verificación no está escondiendo nada necesariamente. Un proyecto que las publica le está diciendo que ha aceptado una restricción, y usted puede verificar que la restricción se cumple.