Un servicio que firma pruebas sobre tus datos tiene una tentación evidente: meter los datos en la prueba. Facilitaría la búsqueda y el soporte, y permitiría un panel más completo. Decidimos pronto que los recibos de Trustvice no lo harían: un recibo lleva el hash de lo que describe, no el contenido.
Este artículo explica por qué y dónde el diseño deja de protegerte sin tu ayuda.
Pruebas que tienen que viajar#
Un recibo solo sirve si puedes dárselo a alguien: un auditor, una contraparte, un mediador. Todo lo que contiene lo puede leer quien lo reciba. Si los recibos llevaran contenido, cada recibo que compartieras filtraría algo, y tendrías que pensar cada vez qué ocultar.
Un hash SHA-256 lo evita. Son 64 caracteres hexadecimales que identifican los bytes exactos de tu contenido sin revelarlos. El recibo dice entonces, en esencia: en este momento se presentaron estos bytes con esta etiqueta. Los bytes los guardas tú. Cuando importa, los aportas, cualquiera calcula su hash, y el hash coincide con el recibo o no.
Dónde no basta con hashear#
Te engañaríamos si nos detuviéramos aquí. Los hashes protegen bien el contenido con una condición, y unos pocos campos de un recibo no son hashes en absoluto.
Un hash oculta el contenido solo en la medida en que este es impredecible#
SHA-256 no se puede invertir, pero sí adivinar. Si la entrada tiene pocas posibilidades, como una respuesta sí o no, un email, un código corto o una plantilla conocida, quien tenga el recibo puede hashear los candidatos y comparar. Para ese tipo de contenido, incluye en lo que hasheas un valor aleatorio, un nonce, y guarda el nonce con el original. Así el recibo prueba la existencia sin dejar que un lector adivine.
Algunos campos se escriben en claro#
Las etiquetas y otros campos de texto libre que eliges se escriben en claro, y una vez firmados en un recibo se quedan ahí. Usa identificadores opacos, como un número de pedido o un id interno, y guarda la tabla de correspondencias de tu lado.
Hashea los bytes exactos#
Un hash identifica bytes, no significado. Un salto de línea final, \r\n en lugar de \n o una normalización Unicode distinta dan otro hash. Para texto, decide una vez la codificación y los finales de línea y mantenlos. Para registros estructurados, guarda los bytes exactos que hasheaste, no una nueva serialización: un JSON.stringify posterior con otro orden de claves da otro hash. Para varios archivos, hashea un manifiesto que liste el hash de cada archivo y atesta el manifiesto.
Conserva tus originales#
Prevé una consecuencia: un recibo no puede reproducir el contenido. Si pierdes el original, el recibo sigue verificándose, pero ya no prueba nada útil sobre un documento que puedas mostrar. Guarda los originales en almacenamiento de una sola escritura, junto a sus recibos.
El borrado y la naturaleza de las pruebas#
Hay un límite que ningún diseño puede eliminar. Un recibo que ya entregaste a otra persona sigue siendo verificable para ella hagamos lo que hagamos, porque verificar solo requiere el recibo y una clave pública. Esa es la propiedad que lo convierte en prueba. También es la razón de que importe el consejo anterior: deja los datos personales fuera de los campos en claro, y la cuestión de borrar un recibo rara vez se complica. Borrar el original en tu propio almacén suele bastar, porque el recibo solo conserva su hash.
En resumen#
Firmamos hechos sobre tus datos, no los datos. Hashear primero significa que los recibos pueden circular y que la verificación nunca exige confiar en nuestro almacenamiento. No hace privado un valor adivinable ni protege lo que escribes en campos de texto en claro. Usa nonces para entradas pequeñas, ids opacos para etiquetas y conserva tus originales.
Más información en Qué prueba un recibo y qué no y en nuestra página de seguridad.
Trustvice 360