Cómo recibir un registro sellado

Para recibir un registro sellado, compartes una dirección de recepción y dejas que tu software encuentre los registros que tus claves pueden abrir. No hay ningún buzón que el servidor llene por ti. Tu cliente recorre el feed público de Label 309, prueba tus claves de recepción contra cada registro sellado y muestra los que logra descifrar.

Esa inversión es la idea central: tu Inbox se descubre por descifrado, no lo asigna un servidor. La cadena nunca lleva un campo de destinatario legible, y el gateway nunca necesita saber qué registros son tuyos.

¿Qué es un registro sellado?

Un registro sellado es una prueba de existencia con el contenido cifrado.

El registro público sigue comprometiéndose con el hash del texto plano, de modo que la prueba podrá demostrar más tarde que ese contenido exacto existía en un momento público de la cadena de bloques. El archivo en sí está cifrado, y el texto cifrado vive en una ubicación direccionada por contenido como Arweave o IPFS, nunca en la cadena. (Para la mecánica de la prueba pública, consulta cómo funciona Label 309.)

Cualquiera que tenga una clave compatible puede descifrar el texto cifrado, recuperar los bytes originales, recalcular el hash del texto plano y confirmar que el archivo descifrado coincide con el compromiso registrado en la cadena. Quien no tiene una clave ve que existe un registro sellado, pero no debería poder leer el contenido.

¿Qué le doy al remitente?

Le das al remitente una dirección de recepción. Nada más.

En los registros sellados de Label 309, las direcciones de recepción se presentan en dos formas:

• age1… — la vía de recepción clásica con X25519.
• age1pqc1… — una vía de recepción híbrida poscuántica (X25519 combinado con ML-KEM-768, en la construcción X-Wing).

Una dirección de recepción es pública y se puede compartir sin riesgo. Permite que alguien cifre un registro para ti y nada más. Se deriva de tu identidad, pero no la revela.

No le des al remitente tu semilla de identidad. La semilla es la raíz privada de tu identidad: los 32 bytes a partir de los cuales se derivan de forma determinista tu clave de firma y tus claves de recepción. Cualquiera que la tenga puede firmar y descifrar haciéndose pasar por ti. (Más sobre por qué la semilla es la verdadera copia de seguridad: tu identidad es una semilla.)

¿Cómo crea el registro el remitente?

El software del remitente hace el sellado localmente. A grandes rasgos:

1. El remitente elige un archivo o un mensaje.
2. El software calcula el hash del texto plano.
3. El software genera una clave de contenido de un solo uso y cifra el contenido.
4. Para cada destinatario, envuelve esa clave de contenido con la clave de recepción del destinatario, produciendo una ranura por destinatario.
5. El texto cifrado se sube a un almacenamiento direccionado por contenido (como ar://).
6. Se publica un registro Label 309 en Cardano, que lleva el hash del texto plano y el sobre sellado.

El registro en la cadena demuestra la cronología y lleva las ranuras de clave envueltas. El texto cifrado almacenado contiene el archivo cifrado. Tu clave privada es lo que abre tu ranura. La misma secuencia —calcular el hash, firmar, sellar, compartir— se recorre en calcula el hash, firma, sella, comparte.

¿Cómo encuentra mi cliente un registro destinado a mí?

Tu cliente recorre los registros públicos e intenta abrirlos.

Esta es la parte que resulta extraña si esperas un buzón normal. En un Inbox alojado, el servidor sabe a qué cuenta pertenece un mensaje y lo enruta. Un registro Label 309 sellado no lleva ese enrutamiento. El sobre enumera las ranuras de clave envueltas, pero ninguna clave pública de destinatario aparece en ningún punto de los datos publicados: no hay ningún campo de destinatario que leer.

Así que tu cliente sincroniza el feed público de registros Label 309 y, para cada registro sellado, prueba si alguna ranura se abre con las claves de recepción de tu identidad. Esto es descifrado de prueba local: un intento de abrir cada ranura, realizado por completo en tu dispositivo. Si una ranura se abre, el registro es tuyo y tu cliente lo añade a tu Inbox. Si no se abre ninguna, tu cliente lo ignora.

Una consecuencia sutil pero importante: el orden de las ranuras tampoco filtra nada. El remitente baraja las ranuras antes de publicar, de modo que ni siquiera la posición de «el destinatario principal» transmite ninguna señal.

¿El descifrado de prueba tiene que descargar cada archivo?

No. El descifrado de prueba se ejecuta sobre el sobre que lleva el registro en la cadena, no sobre el archivo almacenado.

Las ranuras envueltas y una pequeña etiqueta de autenticación viven en los propios metadatos del registro. Tu cliente puede determinar que un registro está dirigido a ti —y recuperar la clave de contenido— solo a partir de esos bytes en la cadena, antes de descargar ningún texto cifrado. Eso importa porque el texto cifrado puede ser grande: un cliente de escritorio puede descubrir primero qué registros son tuyos y luego descargar los archivos cifrados de forma diferida cuando los abres, o cachearlos por adelantado según tu configuración.

Para un cliente que prioriza el funcionamiento sin conexión, esta separación es la base:

• sincroniza el feed público de registros;
• haz el descifrado de prueba localmente contra los sobres;
• cachea el texto cifrado que coincide si lo quieres;
• descifra bajo demanda cuando abres un archivo;
• mantén usable sin red todo lo que ya esté sincronizado.

¿Qué sabe realmente el gateway?

Un gateway sabe lo que sabe cualquier observador público, más los detalles operativos del servicio que opera.

En un gateway alojado, eso puede incluir la actividad de la cuenta, el uso de la API, tu flujo de presupuesto y publicación, la actividad de subida, el estado del saldo, los datos de infraestructura a nivel de red y los metadatos públicos del registro que todo el mundo puede ver. (Para el panorama completo de esa frontera, consulta qué puede ver CardanoWall.)

Lo que no necesita es tu semilla de identidad, tus claves privadas de recepción ni ninguna capacidad de descifrar contenido sellado por ti. La propiedad de privacidad aquí no es «el servidor no aprende nada sobre nada»: eso sería deshonesto. Es más acotada y más útil: la correspondencia de destinatarios y el descifrado ocurren localmente, de modo que no se publica ningún campo de destinatario legible y nunca se envía ninguna clave privada al gateway. El gateway es ciego respecto al destinatario por diseño; cualquier intento de filtrar registros por destinatario simplemente se ignora, porque no hay ninguna columna de destinatario por la que filtrar.

¿Por qué no hay un campo de destinatario público?

Porque un campo de destinatario público filtraría el grafo social.

Si cada registro sellado nombrara exactamente a quién iba dirigido, un observador podría trazar las relaciones entre remitentes y destinatarios sin leer un solo byte de texto plano. Para flujos de trabajo confidenciales —una fuente que contacta con una redacción, una puja sellada, pruebas en custodia— esa exposición puede ser todo el riesgo.

Label 309 usa ranuras de clave envueltas en su lugar. El registro lleva material cifrado que solo los titulares de las claves previstos pueden abrir. Un observador puede ver que un registro está sellado y cuántas ranuras tiene, pero no una lista legible de destinatarios.

Esto no es anonimato perfecto, y no debería venderse como tal. El número de ranuras, el momento de la publicación y los metadatos externos todavía pueden revelar algo, y un remitente que necesite vencer la correlación temporal tiene que publicar fuera de la cronología sensible. Lo que el diseño elimina es la filtración más obvia: una columna pública de destinatarios en un libro mayor permanente.

¿Qué pasa si tengo varias identidades?

Tu cliente prueba cada identidad desbloqueada.

Podrías mantener una identidad para registros personales, otra para una empresa, otra para recepción legal y otra para un canal confidencial de alto riesgo. Cada una tiene su propia semilla y sus propias claves de recepción, así que un registro sellado para una es invisible para las demás hasta que se prueban las claves de esa identidad.

Un cliente que prioriza el funcionamiento sin conexión rastrea hasta dónde ha recorrido cada identidad el feed de registros de forma independiente. Esa independencia es lo que te permite importar una semilla antigua más tarde y hacer que el cliente vuelva a recorrer todo el feed para esa identidad, en lugar de empezar en el día de hoy y dejar pasar en silencio todo lo enviado antes de la importación.

¿Qué ocurre cuando restauro una semilla de identidad antigua?

El software compatible vuelve a derivar las mismas claves de recepción a partir de la semilla, de forma determinista.

Eso significa que una semilla antigua puede encontrar registros sellados antiguos, siempre que los registros sigan en la cadena para poder recorrerlos y el texto cifrado siga siendo recuperable o esté cacheado. El cliente vuelve a recorrer el feed público, hace el descifrado de prueba de los sobres sellados y reconstruye la vista del Inbox para esa identidad. Restaurar la semilla restaura la capacidad de reconocer los registros destinados a ella: el gateway no guarda ningún buzón privado que devolver.

Esta es una de las razones más claras de por qué la semilla importa tanto, y por qué la semilla de identidad sigue mereciendo tu atención. Si pierdes la semilla de una identidad destinataria, los registros sellados dirigidos a ella pueden volverse ilegibles, aunque las pruebas públicas permanezcan en la cadena y sigan verificándose. El cifrado no tiene ninguna puerta trasera de recuperación por diseño; la semilla es la vía de recuperación.

¿Puede un cliente de escritorio recibir registros sin conexión?

Puede trabajar con lo que ya haya sincronizado.

CardanoWall Desktop —una aplicación Rust de código abierto creada con Tauri sobre el SDK Rust de código abierto (github.com/cardanowall)— está construido exactamente en torno a esto. Una vez que ha sincronizado registros y cacheado texto cifrado, lista, busca, verifica y descifra esos datos locales sin ninguna conexión de red. Si un registro aún no se ha sincronizado, o un texto cifrado no se ha descargado, necesita la red para recuperarlos, y lo dice con claridad en lugar de fallar en silencio.

Esto refleja cómo se comporta un cliente de correo serio: estar sin conexión no significa que el mundo se detenga. Tu réplica local, tu caché y tu bóveda se convierten en la fuente de verdad hasta que vuelve la red. (Más sobre el modelo sin conexión: pruebas sin conexión y CardanoWall Desktop.)

¿Cómo debería verificar quién envió un registro?

Recibir un registro sellado solo demuestra que tu clave puede abrirlo. No demuestra quién lo envió.

La autoría en Label 309 es opcional. Si un registro lleva una firma, esa firma muestra que una clave concreta respaldó el registro, pero aun así necesitas contexto para decidir de quién es esa clave. Si un registro no está firmado, puede que el remitente haya evitado deliberadamente vincular ninguna identidad, que es justo lo que requieren algunos flujos de trabajo confidenciales.

Para material sensible, confirma las claves del remitente y las direcciones de recepción por un canal externo: mantén una agenda de contactos, compara las huellas de las claves y usa un directorio o una confirmación directa en la que ya confíes. El cifrado protege el contenido; decidir de quién es la clave con la que hablas es una decisión de confianza humana aparte. La mecánica de la agenda de contactos se explica en cómo funciona la agenda de contactos.

¿Qué puede salir mal?

El fallo más grave es perder la semilla. Pierde la semilla de identidad de una identidad destinataria y puede que pierdas la capacidad de descifrar los registros dirigidos a ella, de forma permanente, para esa identidad.

El resto son operativos, y un buen software debería sacarlos a la luz con honestidad en lugar de ocultarlos:

• el texto cifrado nunca se subió correctamente;
• la ubicación de almacenamiento no está disponible temporalmente;
• el remitente usó la dirección de recepción equivocada;
• importaste la identidad equivocada;
• el dispositivo local está comprometido (un programa malicioso en una máquina desbloqueada puede leer secretos en memoria; consulta modo ordenador público);
• el registro es demasiado nuevo y no ha alcanzado la profundidad de confirmación que exiges;
• el registro es válido pero no está firmado, así que no se establece ninguna identidad del remitente.

Un sistema de pruebas se gana la confianza mostrando la incertidumbre, no tapándola.

La versión corta

Para recibir registros sellados:

1. Comparte una dirección de recepción.
2. Mantén tu semilla de identidad a salvo y con copia de seguridad.
3. Deja que tu cliente recorra el feed público de Label 309.
4. Deja que haga el descifrado de prueba localmente.
5. Abre y verifica los registros que tus claves pueden descifrar.

Tu Inbox no es una lista en el servidor de mensajes dirigidos a tu cuenta. Es una vista local de los registros sellados que tu identidad puede abrir, y eso es precisamente lo que mantiene al gateway fuera de tu correspondencia privada.

Una última nota honesta sobre los límites: un registro sellado mantiene el texto plano cifrado para los titulares de sus claves, pero no garantiza el anonimato, y cualquiera que lo descifre puede decidir filtrar el texto plano después. La prueba demuestra que unos bytes concretos existían en un momento público. No demuestra verdad, propiedad ni autoría; consulta qué no demuestra una prueba.

Lecturas adicionales

• ¿Qué es una dirección de recepción?
• Verifica a un destinatario antes de sellar un archivo
• Divulgación confidencial sin archivos públicos
• El estándar abierto y su código de referencia: label309.org y github.com/cardanowall. Label 309 está presentado al proceso CIP de Cardano y en revisión.